From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,47bc8b783af4aa38 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!j4g2000yqa.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" Date: Mon, 19 Oct 2009 06:28:47 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <5ce2b9d6-478c-4a03-93c0-289e6559e199@l9g2000yqi.googlegroups.com> <4adc5783$0$6556$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1255958927 14184 127.0.0.1 (19 Oct 2009 13:28:47 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 19 Oct 2009 13:28:47 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: j4g2000yqa.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3,gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:8731 Date: 2009-10-19T06:28:47-07:00 List-Id: Georg Bauhaus wrote: > Ludovic Brenta schrieb: > > libopentoken-dev (=3D3.1a+2-1+1) > > Any such expression of the versioning scheme would, sooner or > later, drive package users up several walls IMHO, after tearing > some hair out. Here is why it seems inacceptable: I also dislike it :) > Solution: > Can someone important please mention the availability > of *extended* *file* *attributes*---BTW in *both* file systems > (including UDF) and in standard archive formats such as zip and > tar (hence easily available to deb) ! > With extended file attributes the above information can be > coded almost like this: > > > upstream_ada =3D 3.1a > > upstream_non_ada =3D 2 > > library_ali =3D > > debian_ada_patch =3D 1 > > debian_non_ada_patch =3D 1 > > Do you see the named notation, the XML attributes, and the > property settings? =A0:-) =A0Package handling tools would not > need to have yet another ad hoc, ever changing parser for file > name infixes. =A0Instead, they could use the library routines for > extended file attribute handling. I think you'd need to take this proposal up to the maintainers of dpkg and propose a standard set of attributes and the associated rules for taking these attributes into account when comparing package versions. Also, remember that there can be only one package with a given file name; currently Debian encodes the version in the file name so that archives can carry multiple versions of a package at the same time (e.g. stable, testing and unstable). Your solution seems theoretically sound to me, except for the fact that it is only needed for Ada and a couple other languages like OCaml that care about consistency between source and binaries across the entire closure of a program. Asking for dpkg to support this solution, potentially breaking backward compatibility with archives and making in-place upgrades problematic, all for the sole benefit of these few languages seems politically suicidal :) So far, I still think that encoding the ".ali" version number in the name of the -dev package (e.g. libopentoken3.1a-dev) is the least ugly and least impractical solution. -- Ludovic Brenta.