Re: pkg/47418: pkgin cannot identify upstream version

[George Georgalis <george%galis.org@localhost>]

The following reply was made to PR pkg/47418; it has been noted by GNATS.

From: George Georgalis <george%galis.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: imil%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
pkgsrc-bugs%netbsd.org@localhost
Subject: Re: pkg/47418: pkgin cannot identify upstream version
Date: Thu, 17 Jan 2013 15:16:43 -0800

 On Thu, Jan 17, 2013 at 12:40 AM, David Holland
 <dholland-pbugs%netbsd.org@localhost> wrote:
 > The following reply was made to PR pkg/47418; it has been noted by GNATS.
 >
 > From: David Holland <dholland-pbugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: pkg/47418: pkgin cannot identify upstream version
 > Date: Thu, 17 Jan 2013 08:38:12 +0000
 >
 >  On Wed, Jan 16, 2013 at 12:00:14AM +0000, George Georgalis wrote:
 >   >  >    firefox36-l10n-3.6.28  Language packs for www/firefox36
 >   >  >    firefox36-3.6.28nb4  Web browser with support for extensions 
 > (version 3.6.x)
 >   >  >    firefox10-l10n-10.0.6  Language packs for www/firefox
 >   >  >    firefox10-10.0.7nb3  Web browser with support for extensions 
 > (version 10.x)
 >   >  >    firefox-l10n-15.0.1  Language packs for www/firefox
 >   >  >    firefox-15.0.1nb2    Web browser with support for extensions 
 > (version 15.x)
 >   >
 >   >  I like it, that would certainly be clearer while selecting packages.
 >
 >  I think we can do this.
 
 Super! that would be the big win.
 
 >   >  Do you know a url for naming/numbering convention? cause that wasn't
 >   >  obvious to me.
 >
 >  In pkgsrc, or for firefox itself?
 >
 >  In pkgsrc, packages like "firefox10" normally reflect the most
 >  significant part of the version into the package name; this is to
 >  allow having separate packages for the different versions.
 > ...
 
 thanks for the careful explanation of how that breaks out, your
 experience with exceptions is as informative as the rule. I would
 suggest committing that text as a specification, in ./pkgsrc/pkgtools
 or maybe there is a better location? I'm not sure if/where pkgsrc
 design docs live. I certainly hope it's in the pkgsrc tree!
 
 >  There have been calls/attempts to systematize all this, which is a
 >  worthy goal, but it's never gotten very far, partly because CVS
 >  doesn't have rename and partly because it's just a large undertaking.
 
 I would consider defining where the specification lives, and establish
 it as a reference, for the purpose of more vs less future alignment.
 The level of effort (and fallout consequences) of fixing existing
 irregular patterns is less important than establishing a pattern for
 new projects moving forward (which can coexist with legacy
 irregularities).
 
 
 >   >  I do have a need for the original source url too. For the purpose of
 >   >  downloading original sources and respective licenses in a corporate
 >   >  environment where versions, licenses and the code base is tracked. I
 >   >  appreciate the challenge of mirror site urls, but the issue is not
 >   >  traceability to the url the code is obtained from, so any url should
 >   >  work as long as packages is the same.
 >
 >  For any such tracking scheme that's supposed to actually serve a
 >  useful purpose, you also want at least the patches as well as a
 >  reference to the original source download. And, knowing what a, ahem,
 >  pain some packages are, the pkgsrc makefiles and build support can be
 >  very valuable if you ever need to go back and crosscheck something.
 
 Yeah, that is really a side request, coming from "If I only knew the
 source url I could be sure about the version." In my model, where
 source and license info is recorded for externally developed software,
 it would probably be better to 'make patch' and submit the data from
 that.
 
 On Thu, Jan 17, 2013 at 1:25 AM, David Holland
 <dholland-pbugs%netbsd.org@localhost> wrote:
 >  On Thu, Jan 17, 2013 at 08:40:06AM +0000, David Holland wrote:
 >   >  [...]
 >   >  There have been calls/attempts to systematize all this
 >
 >  ...but I meant to note, the actual *version number*, that is, the part
 >  to the right of the last -, is supposed to be the same as upstream.
 >
 >  There's a small handful of badly behaved packages where this is only
 >  partially true (most notably ffmpeg) and some upstream versions get
 >  canonicalized somewhat in pkgsrc (e.g. 3.5d -> 3.5.4 kinds of things)
 >  but in general the version number part is a safe guide.
 
 Thanks,
 Regards,
 -George
 
 
 
 
 --
 George Georgalis, (415) 894-2710, http://www.galis.org/