Re: .deb filename parsing *again*
On Thu, 9 May 1996, Brian C. White wrote:
> Might I also suggest the following to consider: (no arch, but easily added)
>
> "C" (.*)-([^-]*)-([^-]*)\.deb
> $1 = package-name (with "-")
> $2 = version (without "-")
> $3 = debian revision (no "-")
>
> or
>
> "D" (.*)-([0-9].*)-([^-]*)\.deb
> $1 = package-name (with "-", can't have any "-digit")
> $2 = version (with "-" but must start with a digit)
> $3 = debian revision (no "-")
>
>
> If I recall correctly, my first alternative (C) will affect the fewest
> number of existing packages.
As a "son of B," (the '#' suggestion) might I suggest the following:
(No arch, but easily added here too.)
"E" (.*)-V([0-9].*)-([^-]*)\.deb
$1 = package name (with "-", but can't have any "-Vdigit")
$2 = version (with "-" but must start with a digit)
$3 = debian revision (no "-")
or
"F" (.*)-V(.*)-([^-]*)\.deb
$1 = package name (with "-", but can't have any "-V")
$2 = version (with "-" doesn't have to start with a digit)
$3 = debian revision (no "-")
(i.e. '#' is replaced by the more memorable, more meaningful and less
weird-looking 'V'.)
These would actually be (a bit) more readable the the current scheme for
'naive' users. Once they've seen "Super Foo, V 1.2" in their software
store, they'll know that the V1.2 in "SuperFoo-V1.2-1.i386.deb" means
"version 1.2". And the chances of meeting a piece of software that has a
"-V[0-9]" in its name without it being a version number are just about nil,
precisely because "V[0-9]" brings "Version x" to mind for just about
*everyone* in the computer business.
The big avantage of proposals "C" to "F" are that they will allow package
names to stay the same in the filename. Having stuff like package sysklogd
being in file syslogd-1.3.deb is already confusing enough (especially for
new users)... so I'd rather not have 77 other packages whose filenames
don't quite match their package name! (I also find "foo-bar-biz" easier to
read than "foo_bar_biz", but I guess that's just me.)
IMHO, restricting/changing the 'version' field in the filenames would be
much better (much less confusing, etc.) than restricting/changing the
'package name' field of the filename. People will hardly notice if we
change -1.3-1 to -V1.3-1 or force version numbers not to have dashes. They
*will* notice package names which don't match their filenames.
So I'd strongly urge you to choose a solution that satisfies the following
additional criteria (which I think would be a Good Thing to have, and I
hope others will agree):
*
* After implementation, no package name should be different when
* showing up in the filename.
*
... which would rule out "A".
(Notice all of "C"-"F" allow dots and pretty much anything else in the
'package' field of the filename. So I can't see a reason for package ld.so
being called ldso.*.deb, etc.)
> > A few days ago it occurred to me that in most of the contexts that are
> > relevant here the character # is not a metacharacter. This leads me
> > to suggest, tentatively, the use of
>
> Can't say as I care for that one. '#' is a pretty non-standard character
> for a filename.
And I also don't care very much about "B", for the same reason. If you're
going to pick "B", you might as well pick "E"-"F", IMHO.
I don't really care which of "C"-"F" is chosen, but I'd really rather not
have "A" picked, for the reason given above. And I do think "C"-"F" are
significantly better than "A"-"B", in good part because they allow us to
have a package name that doesn't change/get mangled as soon as it ends up
in a .deb filename. (Well, without the pain/utter mess of having to rename
77 (or whatever the numder was) packages.)
Hopefully, that was convincing enough. I agree parsable filenames would be
a Good Thing. I'd just really rather not have it done the "A" way. Mostly
because I strongly think that if we can find a workable solution that also
satisfies my '***' criteria, then we should go for that. And right now it
looks like we have 4 workable solutions that do satisfy '***'...
<Clambering off soapbox>
Christian
Reply to: