Re: pkg/47418: pkgin cannot identify upstream version

[David Holland <dholland-pbugs%netbsd.org@localhost>]

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.
 
  >  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.
 
 Sometimes it can get confusing; e.g. "firefox36" is 3.6.x, but
 "firefox10" is 10.x, because between upstream 3.6 and 10 upstream
 changed its version numbering policy and the second piece of the
 version is no longer part of the "major" version.
 
 Also, whether the one without a version number in the name is old (as
 in telepathy-mission-control), new (samba, firefox), in between
 (e.g. emacs), or none of the above but a directory in the pkgsrc tree
 that only holds common logic (e.g. squid) varies.
 
 More confusingly, sometimes the extra number appears in the package
 name (it does in firefox) and sometimes it doesn't (emacs, for
 example) and is only found in the pkgsrc tree. This often indicates
 whether the binary packages can be installed simultaneously (python
 can, emacs can't) but not always (I think firefox can't...)
 
 In a few cases the embedded version number includes a '.' (such as
 gstreamer0.10) but mostly it doesn't.
 
 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 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.
 
 My recommendation actually would be to check out the pkgsrc tree and
 use it as part of your tracking scheme... that way you not only have
 the original code but you can reproduce any particular version of the
 software that you had installed in the past.
 
 This depends, though, on whether the company's tracking scheme is an
 asset or a waste of time, because if it's the latter fixing it is
 probably a can of worms...
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost