[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/47418: pkgin cannot identify upstream version
The following reply was made to PR pkg/47418; it has been noted by GNATS.
From: David Holland <dholland-pbugs%netbsd.org@localhost>
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
> > firefox10-l10n-10.0.6 Language packs for www/firefox
> > firefox10-10.0.7nb3 Web browser with support for extensions (version
> > firefox-l10n-15.0.1 Language packs for www/firefox
> > firefox-15.0.1nb2 Web browser with support for extensions (version
> 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
Main Index |
Thread Index |