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 / ' '`
i
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.
[
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.
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
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 packa
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 wou
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 w
>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
"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 das
>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.
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
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 mi
>> 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.
>
>
> ...
> > filenames have the form --.
> > 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
> > separ
...
> filenames have the form --.
> 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 EX
Bill:
> a change in package
> naming conventions which is not backwards compatable with current
> naming conventions might have substantial impact on any 2nd-generation
> mirrors (and those 1st-generation mirrors which don't make special
> arrangements to mitigate the impact)
Yes. Well, we can war
[EMAIL PROTECTED] (Bruce Perens) said:
> 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
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 inte
"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 withou
19 matches
Mail list logo
