NetBSD Problem Report #47418

From www@NetBSD.org  Mon Jan  7 22:24:15 2013
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 2594E63EBAF
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  7 Jan 2013 22:24:15 +0000 (UTC)
Message-Id: <20130107222414.2F68063EBAF@www.NetBSD.org>
Date: Mon,  7 Jan 2013 22:24:14 +0000 (UTC)
From: george@galis.org
Reply-To: george@galis.org
To: gnats-bugs@NetBSD.org
Subject: pkgin cannot identify upstream version
X-Send-Pr-Version: www-1.0

>Number:         47418
>Category:       pkg
>Synopsis:       pkgin cannot identify upstream version
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    imil
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 07 22:25:00 +0000 2013
>Last-Modified:  Mon Dec 30 00:25:00 +0000 2013
>Originator:     George Georgalis
>Release:        6.0 cdrom
>Organization:
>Environment:
NetBSD atom.wsnat 6.0 NetBSD 6.0 (GENERIC) i386
>Description:
Pkgin is a great tool! I've begun using it recently and so far it seems feature full, smooth and efficient.

This is a feature request to identify the upstream src directly with pkgin. This would be useful to identify best package to use when there are multiple options, it is not always clear which represents the newest release.


>How-To-Repeat:
For example, to install the newest version of firefox 

 pkgin search firefox
firefox36-l10n-3.6.28  Language packs for www/firefox36
firefox36-3.6.28nb4  Web browser with support for extensions
firefox10-l10n-10.0.6  Language packs for www/firefox
firefox10-10.0.7nb3  Web browser with support for extensions
firefox-l10n-15.0.1  Language packs for www/firefox
firefox-15.0.1nb2    Web browser with support for extensions

but how would one determine if firefox36 or firefox represents the most current upstream package available?

Since I'm using pkgin, I don't have the pkgsrc cvs tree to grep Makefiles from.



>Fix:
If there is a way to determine url for upstream sources with pkgin, I don't see it. Not sure the best way to integrate with existing command line, but I feel this would be a valuable option.

I could imaging other useful data in the Makefiles, perhaps a pkgin option to dump the specified package's Makefile would work?

>Release-Note:

>Audit-Trail:
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/47418: pkgin cannot identify upstream version
Date: Sun, 13 Jan 2013 20:21:03 +0000

 On Mon, Jan 07, 2013 at 10:25:01PM +0000, george@galis.org wrote:
  > This is a feature request to identify the upstream src directly
  > with pkgin. This would be useful to identify best package to use
  > when there are multiple options, it is not always clear which
  > represents the newest release.
  >
  > [...]
  > 
  >  pkgin search firefox
  > firefox36-l10n-3.6.28  Language packs for www/firefox36
  > firefox36-3.6.28nb4  Web browser with support for extensions
  > firefox10-l10n-10.0.6  Language packs for www/firefox
  > firefox10-10.0.7nb3  Web browser with support for extensions
  > firefox-l10n-15.0.1  Language packs for www/firefox
  > firefox-15.0.1nb2    Web browser with support for extensions
  > 
  > but how would one determine if firefox36 or firefox represents the
  > most current upstream package available?

 Well, in this case because 15.0.1 > 10.0.7 > 3.6.28.

 I agree this isn't abundantly clear in a number of cases. But I think
 this is best handled by improving the COMMENT values for these
 packages, e.g. 

   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)

 or something like that.

  > If there is a way to determine url for upstream sources with pkgin,
  > I don't see it. Not sure the best way to integrate with existing
  > command line, but I feel this would be a valuable option.

 There isn't; this info isn't stored in the package. I suppose it could
 be; it gets a bit tricky with mirror sites though.

 -- 
 David A. Holland
 dholland@netbsd.org

Responsible-Changed-From-To: pkg-manager->imil
Responsible-Changed-By: reed@NetBSD.org
Responsible-Changed-When: Tue, 15 Jan 2013 00:18:51 +0000
Responsible-Changed-Why:
Assign to maintainer
But this ticket seems to be about multiple ideas or requests
and not a bug.


From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/47418 (pkgin cannot identify upstream version)
Date: Tue, 15 Jan 2013 05:22:40 +0000

 On Tue, Jan 15, 2013 at 12:18:52AM +0000, reed@NetBSD.org wrote:
  > Responsible-Changed-Why:
  > Assign to maintainer
  > But this ticket seems to be about multiple ideas or requests
  > and not a bug.

 Yes, it's marked change-request.

 -- 
 David A. Holland
 dholland@netbsd.org

From: George Georgalis <george@galis.org>
To: gnats-bugs@netbsd.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org
Subject: Re: pkg/47418: pkgin cannot identify upstream version
Date: Tue, 15 Jan 2013 15:55:46 -0800

 On Sun, Jan 13, 2013 at 12:25 PM, David Holland
 <dholland-pbugs@netbsd.org> wrote:
 >
 > The following reply was made to PR pkg/47418; it has been noted by GNATS.
 >
 > From: David Holland <dholland-pbugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: pkg/47418: pkgin cannot identify upstream version
 > Date: Sun, 13 Jan 2013 20:21:03 +0000
 >
 >  On Mon, Jan 07, 2013 at 10:25:01PM +0000, george@galis.org wrote:
 >   > This is a feature request to identify the upstream src directly
 >   > with pkgin. This would be useful to identify best package to use
 >   > when there are multiple options, it is not always clear which
 >   > represents the newest release.
 >   >
 >   > [...]
 >   >
 >   >  pkgin search firefox
 >   > firefox36-l10n-3.6.28  Language packs for www/firefox36
 >   > firefox36-3.6.28nb4  Web browser with support for extensions
 >   > firefox10-l10n-10.0.6  Language packs for www/firefox
 >   > firefox10-10.0.7nb3  Web browser with support for extensions
 >   > firefox-l10n-15.0.1  Language packs for www/firefox
 >   > firefox-15.0.1nb2    Web browser with support for extensions
 >   >
 >   > but how would one determine if firefox36 or firefox represents the
 >   > most current upstream package available?
 >
 >  Well, in this case because 15.0.1 > 10.0.7 > 3.6.28.
 >
 >  I agree this isn't abundantly clear in a number of cases. But I think
 >  this is best handled by improving the COMMENT values for these
 >  packages, e.g.
 >
 >    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.
 Do you know a url for naming/numbering convention? cause that wasn't
 obvious to me.

 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.

 --
 George Georgalis, (415) 894-2710, http://www.galis.org/

From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: pkg/47418: pkgin cannot identify upstream version
Date: Wed, 16 Jan 2013 07:57:56 +0100

 On Tue, Jan 15, 2013 at 03:55:46PM -0800, George Georgalis wrote:
 > 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.

 I'm not exactly sure what you need.
 I think all you need is already traceable, but will need some effort.

 Easy part first:
      pkg_info -Q HOMEPAGE firefox
 will give you the homepage for the installed firefox package.

 You can track the pkgsrc versions of used files by looking at
 /var/db/pkg/firefox*/+BUILD_VERSION
 which includes the RCS Ids of the pkgsrc files used; then you
 can visit cvsweb.netbsd.org to look at the corresponding versions
 and extract all the information that's needed.

 Not very comfortable, but I think you're the first that requests these
 particular pieces of information :)
  Thomas

From: George Georgalis <george@galis.org>
To: gnats-bugs@netbsd.org
Cc: imil@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org
Subject: Re: pkg/47418: pkgin cannot identify upstream version
Date: Wed, 16 Jan 2013 14:22:52 -0800

 More specifically, the change request is to identify the source url,
 including the software version, without installing the pkgsrc tree, ie
 with pkgin or another tool available at minimal install.

 Two goals here,
 1) identify most appropriate package prior to install, eg "pkgin search firefox"
 2) generate a report that includes package name, version and url to
 download original source from a minimal environment.

 On Tue, Jan 15, 2013 at 11:00 PM, Thomas Klausner <wiz@netbsd.org> wrote:
 >
 >  Easy part first:
 >       pkg_info -Q HOMEPAGE firefox
 >  will give you the homepage for the installed firefox package.

 I don't have firefox installed, I'd like to review the data to choose
 which package to install. It is also an example, I need to do this
 programmaticly.

 >  You can track the pkgsrc versions of used files by looking at
 >  /var/db/pkg/firefox*/+BUILD_VERSION
 >  which includes the RCS Ids of the pkgsrc files used; then you
 >  can visit cvsweb.netbsd.org to look at the corresponding versions
 >  and extract all the information that's needed.
 >
 >  Not very comfortable, but I think you're the first that requests these
 >  particular pieces of information :)

 I think it's reasonable (for quality, transparency and convenience) to
 integrate reporting of the upstream original sources as part of
 packaging in a minimal environment. So, I've made the request. :)

 At the moment these are significant barriers to using the platform,
 and resolving as-yet unreported issues.

 I'm requesting because while it may be possible to discover this data
 for my immediate issues, it is not practical.

 Regards,
 -George


 -- 
 George Georgalis, (415) 894-2710, http://www.galis.org/

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
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

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/47418: pkgin cannot identify upstream version
Date: Thu, 17 Jan 2013 09:23:35 +0000

 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.

 -- 
 David A. Holland
 dholland@netbsd.org

From: George Georgalis <george@galis.org>
To: gnats-bugs@netbsd.org
Cc: imil@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org
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> wrote:
 > The following reply was made to PR pkg/47418; it has been noted by GNATS.
 >
 > From: David Holland <dholland-pbugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > 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> 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/

From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/47418 CVS commit: pkgsrc/www
Date: Mon, 30 Dec 2013 00:24:08 +0000

 Module Name:	pkgsrc
 Committed By:	dholland
 Date:		Mon Dec 30 00:24:08 UTC 2013

 Modified Files:
 	pkgsrc/www/firefox: Makefile
 	pkgsrc/www/firefox-l10n: Makefile
 	pkgsrc/www/firefox10: Makefile
 	pkgsrc/www/firefox10-l10n: Makefile
 	pkgsrc/www/firefox17: Makefile
 	pkgsrc/www/firefox17-l10n: Makefile
 	pkgsrc/www/firefox24: Makefile
 	pkgsrc/www/firefox24-l10n: Makefile
 	pkgsrc/www/firefox36: Makefile
 	pkgsrc/www/firefox36-l10n: Makefile

 Log Message:
 Update the COMMENTs for the firefox packages to include the upstream
 version number, as suggested in PR 47418 a year ago. Also make sure
 the localization packages claim they belong to the right corresponding
 firefox packages, as a number of them were wrong.


 To generate a diff of this commit:
 cvs rdiff -u -r1.148 -r1.149 pkgsrc/www/firefox/Makefile
 cvs rdiff -u -r1.39 -r1.40 pkgsrc/www/firefox-l10n/Makefile
 cvs rdiff -u -r1.20 -r1.21 pkgsrc/www/firefox10/Makefile
 cvs rdiff -u -r1.11 -r1.12 pkgsrc/www/firefox10-l10n/Makefile
 cvs rdiff -u -r1.19 -r1.20 pkgsrc/www/firefox17/Makefile
 cvs rdiff -u -r1.11 -r1.12 pkgsrc/www/firefox17-l10n/Makefile
 cvs rdiff -u -r1.9 -r1.10 pkgsrc/www/firefox24/Makefile
 cvs rdiff -u -r1.3 -r1.4 pkgsrc/www/firefox24-l10n/Makefile
 cvs rdiff -u -r1.30 -r1.31 pkgsrc/www/firefox36/Makefile
 cvs rdiff -u -r1.11 -r1.12 pkgsrc/www/firefox36-l10n/Makefile

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.