Re: New ftp method for dselect
Robert Leslie writes (Re: New ftp method for dselect): Exceptions: (the ones I saw, anyway) stable/binary/net/bind-4.9.3-BETA24-1.deb debian-1.0/binary/net/bind-4.9.3-BETA26-2.deb If there are no objections I think I will rename the next version of the bind package to something like: bind-4.9.3BETA26-3.* Hopefully this will be kinder to software needing to parse package names. Well, I was going to object, but I see that you've already done it. You might like to consider reversing the change so that people can upgrade without having to invoke dpkg manually (dselect invokes it with --refuse-downgrade). I'll be posting later about how I think the FTP method should be done. Ian.
Re: Parsing package filenames (was: Re: New ftp method for dselect)
On Wed, 20 Dec 1995, Bruce Perens wrote: I we can either rename existing packages, or use the double-dash. I don't care which. ... The most reasonable approach seems to me (of course) to be the one which I've been arguing -- a naming standard very close to current practice, minimizing package renaming, and minimizing mangling of upstream naming and versioning. PKG-VER-REV.EXT PKG: free-form VER: No '-' (perhaps necessitating mangling of upstream versioning) REV: No '.' and No '-' EXT: No '-' -PKG and VER from upstream, mangled by maintainer only as necessary -All parts required for all packages -Debian maintainer to choose appropriate PKG and VER for debain-specific packages and for packages which are splits or joins of upstream packages ... We must, however, make a decision reasonably soon. One of the biggest problems of Debian, and the one that still may cause it to fail, is it's design-by-committee nature. If we are to argue this issue for three weeks, we'd might as well quit now. Past practice to terminate protracted discussion and move on to action has been for Ian M to make a decision based on the info brought out by discussion and proclaim that that's the way it'll be done. I'd accept such a proclimation from you, barring opposition from Ian M. Whatever decision is made, it should be expressed in updated packaging guidelines on project/standards.
Re: Parsing package filenames (was: Re: New ftp method for dselect)
From: Bill Mitchell [EMAIL PROTECTED] I'd accept such a proclimation from you, barring opposition from Ian M. I'm not going to make a proclamation this time. I'm going on vacation. I didn't want to return to the same situation, though :-) . I was hoping that I'd be able to upload my remaining packages in ELF form, leave for a while, and when I came back all of the problems of Debian would be resolved :-) . Once we decide on a package naming standard, we should tell the rest of the free software world what it is and encourage the upstream maintainers to stick to that format. Thanks Bruce -- Bruce Perens [EMAIL PROTECTED] Pixar Animation Studios
Re: Parsing package filenames (was: Re: New ftp method for dselect)
Bill Mitchell writes: The most reasonable approach seems to me (of course) to be the one which I've been arguing -- a naming standard very close to current practice, minimizing package renaming, and minimizing mangling of upstream naming and versioning. Let me throw another idea in the pot. A has been pointed out, any naming system invites violations in upstream names or versions. Why not do what Red Hat has done, and have a site exec command to return the header (dpkg --info package) which can be called on packages with unweildy names. This isn't *instead of* the other suggestions, but allows for the unweildy cases without contortions. As far as I can tell, you either have filesystem access to packages, in which case you can call dpkg directly, or you have ftp access, in which case you could call a site exec command to differentiate. Food for thought. There are plenty of arguments to be made against it, one of which is but what if the site foo doesn't enable the site exec command?, but it's worth consideration. michaelkjohnson
Re: Parsing package filenames (was: Re: New ftp method for dselect)
Once we decide on a package naming standard, we should tell the rest of the free software world what it is and encourage the upstream maintainers to stick to that format. Tell them without asking for comments? :-) [What was that about committees?] I lean towards Bill Mitchell's idea. [1] it matches prior discussions on the subject [2] less entropy in dumb conversion to msdos [3] minimal effort to bring packages into conformance -- Raul (70 unread messages remaining)
Re: Parsing package filenames (was: Re: New ftp method for dselect)
Brian White: (the above is csh code... sorry!) I've not been following this discussion very closely, but here's a fairly literal translation of Brian's speedup to sh: for FILE in `sed -e 's/\(.*\)-\([^-]*\)-\([^.-]*\)\.\([^-]*\)$/\1/\2/\3/\4/'` do ( set `echo $FILE|tr / ' '` if [ $# = 4 ] then nam=$1 ver=$2 rev=$3 ext=$4 # do processing here # ... else echo Error: bad file `echo $FILE|tr / -` fi ) done Note that I've decided to use a slash as a delimiter to allow for the odd-ball case of a package which has a comma in its name. If / is a bad idea, the regexp should also be changed to have an optional directory prefix. -- Raul
Re: Parsing package filenames (was: Re: New ftp method for dselect)
Personally, I also think we'll be better off if we bite the bullet and try to maintain as much backwards compatability as we can with current package naming usage than if we fall into a pattern of blowing off backwards compatability issues in the interest of implementor convenience. What programs are we talking about being compatible with? Not dselect or dpkg, which don't care about the filename. I'd hazard that dchanges would be easy to fix. Dftp would ask for the feature, as would the dselect FTP method. I think he was trying to say that it would be better to alter a few packages to conform to the package-name-version-revision.deb convention (with dashes in the packages-name an nowhere else) than rename all existing files to have double-dashes (--) in them. Personally, I agree. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Parsing package filenames (was: Re: New ftp method for dselect)
On Tue, 19 Dec 1995, Bruce Perens wrote: [...] What programs are we talking about being compatible with? Not dselect or dpkg, which don't care about the filename. I'd hazard that dchanges would be easy to fix. Dftp would ask for the feature, as would the dselect FTP method. Am I missing something? Yes, I think you are missing the whole sunsite and tsx archives, which store packages with an almost standard format. Even though they are not Debian packages right now, some (many?) could be in the future. And the debianized name should be as close to the upstream name as possible. Adding a revision number between the package-and-version block and the extension (almost always tar.gz or tgz) is OK, but touching something within the package-and-version block (which was chosen by the original author) seems to me as an intrusion.
Re: Parsing package filenames (was: Re: New ftp method for dselect)
Fernando Alegre [EMAIL PROTECTED] said: [...] the whole sunsite and tsx archives, which store packages with an almost standard format. Even though they are not Debian packages right now, some (many?) could be in the future. And the debianized name should be as close to the upstream name as possible. Adding a revision number between the package-and-version block and the extension (almost always tar.gz or tgz) is OK, but touching something within the package-and-version block (which was chosen by the original author) seems to me as an intrusion. That sounds like a very good point. Also, most current packages probably already conform to this. One major difference between this and our current naming scheme is that this leaves open the possibility of a non-'-' separator, or no separator at all, between package and version, while we presently require a '-'. Another major difference is that Version does not seem to be guaranteed to be machine-parseable from package-and-version. I think having the upstream version as a separate and identifiable field is probably too deeply ingrained into our package handling procedures to consider changing that at this point. A mostly-compatable compromise would seem to be: Package-Version-Revision.Extension Package: Retained unchanged. May contain any printable chars. Maintainer makes a judgement regarding the separation of the upstream package and version fields. If they're not separated by a '-' in the upstream package-and-version field, maintainer mangles the package-and-version field from upstream to debianize it as package-version. Version: Debian package naming conventions forbid embedded '-' chars in version numbers. Maintainer mangles the upstream version number as necessary to eliminate any of these. Most packages should not need to have their upstream package-and-version field mangled, but some will. Revision: Added by debian package maintainer. Usually numeric, but may contain any printable chars except '.'. Extension: May contain any printable chars.
Re: Parsing package filenames (was: Re: New ftp method for dselect)
A mostly-compatable compromise would seem to be: [...] Extension: May contain any printable chars. If the extension can contain dashes, once again it could cause parsing problems. Eliminating dashes (or dots, for that matter) here would again make it fit into a regular expression. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Parsing package filenames (was: Re: New ftp method for dselect)
brian (b.c.) white [EMAIL PROTECTED] said: If the extension can contain dashes, once again it could cause parsing problems. Eliminating dashes (or dots, for that matter) here would again make it fit into a regular expression. Yup. Thanks for pointing that out. EXT should disallow dashes. The following seems to (slowly) parse all packages in a fairly old available file which I have handy as is apparently intended by the debian package maintainer, with the exception of gopher-client-2.1.1-2.tar.gz (spurious quotes) gopherd-2.1.1-2.tar.gz (spurious quotes) elisp-manual-19-2.4-1.tar.gz (is -19 part of Name or Veraion?) lrzsz-0.11.tar.gz(Revision? Should be lrzsz-0-11.tar.gz?) bind-4.9.3-BETA24-1.tar.gz (change to bind-4.9.3_BETA24-1.tar.gz?) for FILE in $* do TOKENS=`echo $FILE | \ sed -e 's/\(.*\)-\([^-]*\)-\([^.]*\)\.\([^-]*\)$/\1 \2 \3 \4/'` PKG=`echo $TOKENS | cut -d' ' -f1` VER=`echo $TOKENS | cut -d' ' -f2` REV=`echo $TOKENS | cut -d' ' -f3` EXT=`echo $TOKENS | cut -d' ' -f4` echo $PKG $VER$REV$EXT done
Re: Parsing package filenames (was: Re: New ftp method for dselect)
Yup. Thanks for pointing that out. EXT should disallow dashes. The following seems to (slowly) parse all packages in a fairly old available file which I have handy as is apparently intended by the debian package maintainer, with the exception of elisp-manual-19-2.4-1.tar.gz (is -19 part of Name or Veraion?) 19 is (I believe) part of the package name. lrzsz-0.11.tar.gz(Revision? Should be lrzsz-0-11.tar.gz?) ?bind-4.9.3-BETA24-1.tar.gz (change to bind-4.9.3_BETA24-1.tar.gz?) There is also dpkg-1.0.5.deb which has no revision. It isn't strictly neccessary and so has been left out. In order to use this scheme, such packages would have to include a dummy revision of -0 or something. for FILE in $* do TOKENS=`echo $FILE | \ sed -e 's/\(.*\)-\([^-]*\)-\([^.]*\)\.\([^-]*\)$/\1 \2 \3 \4/'` You might want [^.-] here--- PKG=`echo $TOKENS | cut -d' ' -f1` VER=`echo $TOKENS | cut -d' ' -f2` REV=`echo $TOKENS | cut -d' ' -f3` EXT=`echo $TOKENS | cut -d' ' -f4` echo $PKG $VER$REV$EXT done I don't see how to accelerate your regex, but you can accelerate the loop by forking as few external process as possible. eg: Run sed only once: for FILE in `sed -e '.' FileOfPackagesOnePerLine` (be sure to put something besides spaces (like ,) between the different pieces or each piece will pass through the loop) Break the tokens up in one shot and use shell operators: set pkg = ( `echo $file | sed -e 's|,| |g'` ) if ($#pkg != 3) then echo Error: bad file $file continue endif set nam = $pkg[1] set ver = $pkg[2] set rev = $pkg[3] (the above is csh code... sorry!) Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Parsing package filenames (was: Re: New ftp method for dselect)
Since I don't really have anything invested in this debate, I'll throw in my last two cents and shut up. It seems to me that changing the very few packages which don't already conform to such a naming scheme would be much less disruptive than renaming every package. Also, a cheap workaround for any existing dependency problems would be a Provides: entry with the old package name. -- Raul
Re: Parsing package filenames (was: Re: New ftp method for dselect)
Someone (David?) said: It seems to me that changing the very few packages which don't already conform to such a naming scheme would be much less disruptive than renaming every package. From: Raul Miller [EMAIL PROTECTED] Also, a cheap workaround for any existing dependency problems would be a Provides: entry with the old package name. I we can either rename existing packages, or use the double-dash. I don't care which. We must, however, make a decision reasonably soon. One of the biggest problems of Debian, and the one that still may cause it to fail, is it's design-by-committee nature. If we are to argue this issue for three weeks, we'd might as well quit now. Bruce -- Bruce Perens [EMAIL PROTECTED] Pixar Animation Studios
Re: New ftp method for dselect
OK, so package file names don't parse easily. Why couldn't the cross reference be included in the Packages file? It's needed by dselect anyway. Also, what about packages like ld.so where the file name doesn't match the package name (ldso)? What am I missing? You're not missing anything. Months ago, I tried to get the filename standardized so my dftp program could properly get version info from the filename. This eventually led nowhere. 1) Nobody wants to change the names of existing packages. The ldso maintainer flat-out refused to match the filename to the package name. Having a daemon automatically rename packages was also discarded. 2) Some version-strings start with a letter so you can't use -[0-0] to locate the start of the version, though I think this still matches more names than most other methods. 3) Both version-strings and package-names may contain dashes so dashes cannot be used to flawlessly determine where versions revisions are. 4) Some packages (notably dpkg) doesn't even have a revision number. If the primary people involved won't standardize the name on their own packages, don't count on it getting done. As a concession, the filename of each packages has been put into the Packages file at the top of each directory hierachy. The Packages-Master contains (I believe) all of the stable and contrib packages. The expermental hierarchy has no Packages file because Ian wishes people not to be able to accidentally download from there. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: New ftp method for dselect
Dirk Eddelbuettel writes (supercite undone - iwj): [Ian Jackson writes:] Right. In order to avoid having to rename lots of packages or change their version numbers I propose the following naming scheme for files on the FTP site in the `binary' directory: package-name--version[-revision].deb Note the two hyphens. Could such a measure be announced 24 to 48 hours in advance, and ideally be complemented by a script that can be used for renaming the files on the local tree? Yes, of course. Otherwise folks like me will have to refetch about 110 Megabytes of */binary/* stuff. Not that much fun over a phone line. Some people even have to pay for every bytes they get through their phone. Indeed. Ian.
Re: New ftp method for dselect
Bill Mitchell writes (Re: New ftp method for dselect): dchanges(1) seems to parse distribution filenames OK, though the parsing code is pretty ugly. If it's broken, please let me know. Seems to do it OK isn't good enough - we need something unambiguous and predictable. Ian.
Re: New ftp method for dselect
David Engel writes (Re: New ftp method for dselect): OK, so package file names don't parse easily. Why couldn't the cross reference be included in the Packages file? It's needed by dselect anyway. Also, what about packages like ld.so where the file name doesn't match the package name (ldso)? What am I missing? There already is a cross-reference in the Packages file. However, the dselect ftp method needs to be able to recognise what a file is even in the gap between the file being moved into view and the Packages file being updated. Otherwise it would have to download it `on spec'. Ian.
Re: New ftp method for dselect
(Replying to my own message -- bad, I know...) 3) Both version-strings and package-names may contain dashes so dashes cannot be used to flawlessly determine where versions revisions are. I looked into this more closely and it seems that most of the packages that once had dashes in the version stings are now gone. If neither the version nor revision strings can have dashes, then counting -'s will break up the filename without having rename all the packages with -- in them. Exceptions: (the ones I saw, anyway) stable/binary/net/bind-4.9.3-BETA24-1.deb debian-1.0/binary/net/bind-4.9.3-BETA26-2.deb Of course, this requires all fields to be present (including revision) even if they are not strictly neccessary (eg. dpkg). 4) Some packages (notably dpkg) doesn't even have a revision number. If the primary people involved won't standardize the name on their own packages, don't count on it getting done. Hmmm... Reading this again it seems rather harsh. My appologies! It was not intended as such. C932 Unix Guru Brian x37930, Lab-3, 3F18 --- In theory, theory and practice are the same. In practice, they're not.
Re: New ftp method for dselect
Ian Jackson [EMAIL PROTECTED] said: Bill Mitchell writes (Re: New ftp method for dselect): dchanges(1) seems to parse distribution filenames OK, though the parsing code is pretty ugly. If it's broken, please let me know. Seems to do it OK isn't good enough - we need something unambiguous and predictable. No argument from me about that. In the meantime I'll try to work with what we've got, per ftp.debian.org:/debian/project/standards/Guidelines.
Re: New ftp method for dselect
Exceptions: (the ones I saw, anyway) stable/binary/net/bind-4.9.3-BETA24-1.deb debian-1.0/binary/net/bind-4.9.3-BETA26-2.deb If there are no objections I think I will rename the next version of the bind package to something like: bind-4.9.3BETA26-3.* Hopefully this will be kinder to software needing to parse package names. -- Robert Leslie [EMAIL PROTECTED]
Parsing package filenames (was: Re: New ftp method for dselect)
brian (b.c.) white [EMAIL PROTECTED] said: I looked into this more closely and it seems that most of the packages that once had dashes in the version stings are now gone. If neither the version nor revision strings can have dashes, then counting -'s will break up the filename without having rename all the packages with -- in them. Exceptions: (the ones I saw, anyway) stable/binary/net/bind-4.9.3-BETA24-1.deb debian-1.0/binary/net/bind-4.9.3-BETA26-2.deb Also: Package: cern-httpd Package: elv-fmt Package: auto-pgp Package: linuxdoc-sgml Package: ncurses-runtime Package: electric-fence Package: boot-floppies Package: ax25-kernel-source Package: gopher-client Package: w3-el Package: arrl-infoserv Package: elv-vi Package: emacs-el Package: elisp-manual Package: mt-st Package: ax25-util Package: mh-papers Package: ncurses-developer Package: pgp-i Package: pgp-us Package: wu-ftpd Package: elv-ctags Personally, I also think we'll be better off if we bite the bullet and try to maintain as much backwards compatability as we can with current package naming usage than if we fall into a pattern of blowing off backwards compatability issues in the interest of implementor convenience. I believe that the vast majority of packages currently follow these conventions: filenames have the form PKG-VER-REV.EXT e.g.: ab-cd-1.23a-45678.tar.gz Field Separators:- - . Field Contents: ab-cd 1.23a 45678 tar.gz Reading from right to left: EXT is currently either .deb, .changes, .tar.gz, .diff.gz. It might be restricted to alphanumerics and '.' chars. '.' currently separates REV from EXT REV typically is numeric only. It might be restricted to alphanumerics. There's been some talk of some packages not providing this field, but it might be made mandatory. '-' currently separates EXT from VER VER typically contains numerics, but alphas and '.' chars are not uncommon. I think there's only one case of a '-' in VER: bind-4.9.3-BETA24-1. The current convention, not always followed 100.00%, is that VER should track the upstream maintainer's version number. We might relax this to the extent of restricting VER to not contain any '-' chars. '-' chars in upstream version numbers could be transliterated to '.' or '_'. '-' currently separates VER from PKG PKG typically contains alphanumerics. In some cases, it contains '-' chars. It's typically taken from the upstream source code author's name, which could contain any printable chars. This cannot be restricted without relaxing the (IMO sensible) convention that debian package names track the upstream package name. (That convention isn't followed in all cases. Exceptions generally occur when the a debian package is a split or a join of upstream packages, and where multiple binary packages are produced from a single source package.) Counting from the end towards the front of the typical package filename string, the first '-' encountered separates REV from VER. Take that as a reference point. - Counting to the right from that point, the first '.' encountered separates REV from EXT. Whitespace to the right of EXT delimits it. - Counting to the left from that point, the first '-' encountered separates PKG from VER Whitespace to the left of PKG delimits it. That's a bit messy, but maintaining backwards compatability is often messy. Blowing off backwards compatability whenever maintaining it gets inconvenient is a tempting option, but not something which should not become a habit (IMHO).
Re: Parsing package filenames (was: Re: New ftp method for dselect)
From: Bill Mitchell [EMAIL PROTECTED] Personally, I also think we'll be better off if we bite the bullet and try to maintain as much backwards compatability as we can with current package naming usage than if we fall into a pattern of blowing off backwards compatability issues in the interest of implementor convenience. What programs are we talking about being compatible with? Not dselect or dpkg, which don't care about the filename. I'd hazard that dchanges would be easy to fix. Dftp would ask for the feature, as would the dselect FTP method. Am I missing something? Thanks Bruce -- Bruce Perens [EMAIL PROTECTED] Pixar Animation Studios
Re: Parsing package filenames (was: Re: New ftp method for dselect)
...
filenames have the form PKG-VER-REV.EXT
e.g.: ab-cd-1.23a-45678.tar.gz
Field Separators:- - .
Field Contents: ab-cd 1.23a 45678 tar.gz
...
- Counting to the right from that point, the first '.' encountered
separates REV from EXT. Whitespace to the right of EXT delimits it.
- Counting to the left from that point, the first '-' encountered
separates PKG from VER Whitespace to the left of PKG delimits it.
FWIW, _all_ RedHat (i386) packages conform to the regular expression
sed /^${PKG}-[^-]*-[^-]*\.i386\.rpm$/p`
PKG - VER - REV . EXT
Since I don't really have anything invested in this debate, I'll throw
in my last two cents and shut up. It seems to me that changing the
very few packages which don't already conform to such a naming scheme
would be much less disruptive than renaming every package.
David
--
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED] 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Re: New ftp method for dselect
Bruce Perens writes (Re: New ftp method for dselect): I used Andy Guy's FTP method for dselect to upgrade a bunch of ELF packages automaticaly this evening. It worked very well, and even detected corrupt and partially-downloaded packages when I used a kernel with networking problems. Good ! I could make the bootstrap floppies support an FTP installation if you would do the work necessary to integrate this method into dselect. To do this you need a package naming standard - perhaps a deviation from your plan, but easy enough to do and it would be of great benefit to us in the short term. Of course we could handle it differently in the long term. Right. In order to avoid having to rename lots of packages or change their version numbers I propose the following naming scheme for files on the FTP site in the `binary' directory: package-name--version[-revision].deb Note the two hyphens. Andy, can you make a version of your method that knows about this ? We can then go through the 1.0 tree renaming the files. (Unfortunately this will mess up mirror sites, so we should do it slowly, perhaps one directory at a time.) If this turns out to be good we can do it to the 0.93 tree too. Ian.
Re: New ftp method for dselect
Ian Jackson writes: Ian Right. In order to avoid having to rename lots of packages or change Ian their version numbers I propose the following naming scheme for files Ian on the FTP site in the `binary' directory: Ian Ian package-name--version[-revision].deb Ian Ian Note the two hyphens. Could such a measure be announced 24 to 48 hours in advance, and ideally be complemented by a script that can be used for renaming the files on the local tree? Otherwise folks like me will have to refetch about 110 Megabytes of */binary/* stuff. Not that much fun over a phone line. Some people even have to pay for every bytes they get through their phone. -- Dirk Eddelb|ttelhttp://qed.econ.queensu.ca/~edd
Re: New ftp method for dselect
I could make the bootstrap floppies support an FTP installation if you would do the work necessary to integrate this method into dselect. To do this you need a package naming standard - perhaps a deviation from your plan, but easy enough to do and it would be of great benefit to us in the short term. Of course we could handle it differently in the long term. Right. In order to avoid having to rename lots of packages or change their version numbers I propose the following naming scheme for files on the FTP site in the `binary' directory: package-name--version[-revision].deb Note the two hyphens. I missed the first part of this thread. Sorry. What is the resoning for this drastic change? David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: New ftp method for dselect
I missed the first part of this thread. Sorry. What is the resoning for this drastic change? Distribution file names don't parse at the moment because you can't disambiguate the package name from the version number. I had suggested that we standardize package names so that FTP scripts would work better and would not have to carry around a package-to-filename cross-reference. It's a bit more ugly, I agree. OK, so package file names don't parse easily. Why couldn't the cross reference be included in the Packages file? It's needed by dselect anyway. Also, what about packages like ld.so where the file name doesn't match the package name (ldso)? What am I missing? David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: New ftp method for dselect
From: [EMAIL PROTECTED] (David Engel) OK, so package file names don't parse easily. Why couldn't the cross reference be included in the Packages file? It's needed by dselect anyway. Also, what about packages like ld.so where the file name doesn't match the package name (ldso)? What am I missing? The cross-reference is sufficient. It would be easier to run naive scripts on debian packages if there were a naming standard. Under the proposed standard, ldso would be named ld.so--1.7.11-1.deb . Thanks Bruce -- Bruce Perens [EMAIL PROTECTED] Pixar Animation Studios
Re: New ftp method for dselect
David Engel wrote: OK, so package file names don't parse easily. Why couldn't the cross reference be included in the Packages file? It's needed by dselect anyway. Also, what about packages like ld.so where the file name doesn't match the package name (ldso)? What am I missing? Working towards consistent naming schemes is an excellent goal, but there will always be the defiant package that breaks something (ldso is a perfect example). So, an _optional_ cross-reference entry in the Packages file would be a fine way of fixing the problem names. I believe that several people posted regexps that covered (nearly) all cases. Quite beyond me, really. Here's a package that is begging to come out and break dselect: Package: g-- priority: optional section: devel maintainer: S.T. Box [EMAIL PROTECTED] version: 1.0.2 revision: 1 filename: debian-0.93/binary/devel/g1.0.1-1.deb description: The GNU C++ compiler for inexpensive, set-top box designs. Sorry, but it just came to me. The point is that there will always be something that messes with our naming convention. -- Jeffrey Ebert [EMAIL PROTECTED]
