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:    jperkin
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 07 22:25:00 +0000 2013
>Closed-Date:    Wed Apr 22 07:04:31 +0000 2020
>Last-Modified:  Tue Aug 18 09:45:01 +0000 2020
>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.

Responsible-Changed-From-To: imil->pkg-manager
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Mon, 02 Apr 2018 09:32:54 +0000
Responsible-Changed-Why:
imil observes


Responsible-Changed-From-To: pkg-manager->jperkin
Responsible-Changed-By: jperkin@NetBSD.org
Responsible-Changed-When: Tue, 03 Apr 2018 14:33:23 +0000
Responsible-Changed-Why:
I'll take this.


State-Changed-From-To: open->closed
State-Changed-By: jperkin@NetBSD.org
State-Changed-When: Mon, 20 Apr 2020 10:50:30 +0000
State-Changed-Why:
The firefox-related parts of this PR were resolved a while back.  As for
the pkgin parts, you can identify the HOMEPAGE of a package using pkgin
with "pkgin pkg-build-defs <pkg> | grep HOMEPAGE", and from that be able
to find the source files, or grep for PKGPATH to find where all the pkgsrc
related files are kept for the package in question.


From: George Georgalis <george@galis.org>
To: gnats-bugs@netbsd.org
Cc: jperkin@netbsd.org, pkgsrc-bugs@netbsd.org, gnats-admin@netbsd.org
Subject: Re: pkg/47418 (pkgin cannot identify upstream version)
Date: Mon, 20 Apr 2020 05:29:30 -0700

 --000000000000a9ae8305a3b80df0
 Content-Type: text/plain; charset="UTF-8"

 The State-Changed-Why open->closed indicates jperkin doesn't understand
 this request or the value of it.

 It would be _very_ valuable to query the actual source file used by pkgsrc
 (url, and revision if it is a repo), vs what is currently in use on the
 website.

 ie, the change-request is to provide a reporting of the version
 configuration USED by pkgsrc.

 This has value for research of installed packages as well as packages
 considered for installation.

 It will address the situation of a known feature or bug (per HOMEPAGE) and
 determination if pkgsrc is inclusive.





 On Mon, Apr 20, 2020 at 3:50 AM <jperkin@netbsd.org> wrote:

 > Synopsis: pkgin cannot identify upstream version
 >
 > State-Changed-From-To: open->closed
 > State-Changed-By: jperkin@NetBSD.org
 > State-Changed-When: Mon, 20 Apr 2020 10:50:30 +0000
 > State-Changed-Why:
 > The firefox-related parts of this PR were resolved a while back.  As for
 > the pkgin parts, you can identify the HOMEPAGE of a package using pkgin
 > with "pkgin pkg-build-defs <pkg> | grep HOMEPAGE", and from that be able
 > to find the source files, or grep for PKGPATH to find where all the pkgsrc
 > related files are kept for the package in question.
 >
 >
 >
 >

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

 --000000000000a9ae8305a3b80df0
 Content-Type: text/html; charset="UTF-8"
 Content-Transfer-Encoding: quoted-printable

 <div dir=3D"ltr"><div>The State-Changed-Why open-&gt;closed indicates jperk=
 in doesn&#39;t understand this request or the value of it.</div><div><br></=
 div><div>It would be _very_ valuable to query the actual source file used b=
 y pkgsrc (url, and revision if it is a repo), vs what is currently in use o=
 n the website.</div><div><br></div><div>ie, the change-request is to provid=
 e a reporting of the version configuration USED by pkgsrc.</div><div><br></=
 div><div>This has value for research of installed packages as well as packa=
 ges considered for installation.</div><div><br></div><div>It will address t=
 he situation of a known feature or bug (per HOMEPAGE) and determination if =
 pkgsrc is inclusive.<br></div><div><br></div><div><br></div><div><br></div>=
 <div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
 =3D"gmail_attr">On Mon, Apr 20, 2020 at 3:50 AM &lt;<a href=3D"mailto:jperk=
 in@netbsd.org">jperkin@netbsd.org</a>&gt; wrote:<br></div><blockquote class=
 =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
 b(204,204,204);padding-left:1ex">Synopsis: pkgin cannot identify upstream v=
 ersion<br>
 <br>
 State-Changed-From-To: open-&gt;closed<br>
 State-Changed-By: jperkin@NetBSD.org<br>
 State-Changed-When: Mon, 20 Apr 2020 10:50:30 +0000<br>
 State-Changed-Why:<br>
 The firefox-related parts of this PR were resolved a while back.=C2=A0 As f=
 or<br>
 the pkgin parts, you can identify the HOMEPAGE of a package using pkgin<br>
 with &quot;pkgin pkg-build-defs &lt;pkg&gt; | grep HOMEPAGE&quot;, and from=
  that be able<br>
 to find the source files, or grep for PKGPATH to find where all the pkgsrc<=
 br>
 related files are kept for the package in question.<br>
 <br>
 <br>
 <br>
 </blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
 mail_signature">George Georgalis, (415) 894-2710, <a href=3D"http://www.gal=
 is.org/" target=3D"_blank">http://www.galis.org/</a><br><br></div>

 --000000000000a9ae8305a3b80df0--

From: George Georgalis <george@galis.org>
To: jperkin@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org, 
	gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/47418 (pkgin cannot identify upstream version)
Date: Mon, 20 Apr 2020 05:35:21 -0700

 The State-Changed-Why open->closed indicates jperkin doesn't
 understand this request or the value of it.

 It would be _very_ valuable to query the actual source file used by
 pkgsrc (url, and revision if it is a repo), vs what is currently in
 use on the website.

 ie, the change-request is to provide a reporting of the version
 configuration USED by pkgsrc.

 This has value for research of installed packages as well as packages
 considered for installation.

 It will address the situation of a known feature or bug (per HOMEPAGE)
 and determination if pkgsrc is inclusive.

 If a package author is concerned about the package version used, the
 package user certainly is. This request is about reporting what WAS
 used in pkgsrc.


 On Mon, Apr 20, 2020 at 5:30 AM George Georgalis <george@galis.org> wrote:
 >
 > The following reply was made to PR pkg/47418; it has been noted by GNATS.
 >
 > From: George Georgalis <george@galis.org>
 > To: gnats-bugs@netbsd.org
 > Cc: jperkin@netbsd.org, pkgsrc-bugs@netbsd.org, gnats-admin@netbsd.org
 > Subject: Re: pkg/47418 (pkgin cannot identify upstream version)
 > Date: Mon, 20 Apr 2020 05:29:30 -0700
 >
 >  --000000000000a9ae8305a3b80df0
 >  Content-Type: text/plain; charset="UTF-8"
 >
 >  The State-Changed-Why open->closed indicates jperkin doesn't understand
 >  this request or the value of it.
 >
 >  It would be _very_ valuable to query the actual source file used by pkgsrc
 >  (url, and revision if it is a repo), vs what is currently in use on the
 >  website.
 >
 >  ie, the change-request is to provide a reporting of the version
 >  configuration USED by pkgsrc.
 >
 >  This has value for research of installed packages as well as packages
 >  considered for installation.
 >
 >  It will address the situation of a known feature or bug (per HOMEPAGE) and
 >  determination if pkgsrc is inclusive.
 >
 >
 >
 >
 >
 >  On Mon, Apr 20, 2020 at 3:50 AM <jperkin@netbsd.org> wrote:
 >
 >  > Synopsis: pkgin cannot identify upstream version
 >  >
 >  > State-Changed-From-To: open->closed
 >  > State-Changed-By: jperkin@NetBSD.org
 >  > State-Changed-When: Mon, 20 Apr 2020 10:50:30 +0000
 >  > State-Changed-Why:
 >  > The firefox-related parts of this PR were resolved a while back.  As for
 >  > the pkgin parts, you can identify the HOMEPAGE of a package using pkgin
 >  > with "pkgin pkg-build-defs <pkg> | grep HOMEPAGE", and from that be able
 >  > to find the source files, or grep for PKGPATH to find where all the pkgsrc
 >  > related files are kept for the package in question.
 >  >
 >  >
 >  >
 >  >
 >
 >  --
 >  George Georgalis, (415) 894-2710, http://www.galis.org/
 >
 >  --000000000000a9ae8305a3b80df0
 >  Content-Type: text/html; charset="UTF-8"
 >  Content-Transfer-Encoding: quoted-printable
 >
 >  <div dir=3D"ltr"><div>The State-Changed-Why open-&gt;closed indicates jperk=
 >  in doesn&#39;t understand this request or the value of it.</div><div><br></=
 >  div><div>It would be _very_ valuable to query the actual source file used b=
 >  y pkgsrc (url, and revision if it is a repo), vs what is currently in use o=
 >  n the website.</div><div><br></div><div>ie, the change-request is to provid=
 >  e a reporting of the version configuration USED by pkgsrc.</div><div><br></=
 >  div><div>This has value for research of installed packages as well as packa=
 >  ges considered for installation.</div><div><br></div><div>It will address t=
 >  he situation of a known feature or bug (per HOMEPAGE) and determination if =
 >  pkgsrc is inclusive.<br></div><div><br></div><div><br></div><div><br></div>=
 >  <div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
 >  =3D"gmail_attr">On Mon, Apr 20, 2020 at 3:50 AM &lt;<a href=3D"mailto:jperk=
 >  in@netbsd.org">jperkin@netbsd.org</a>&gt; wrote:<br></div><blockquote class=
 >  =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
 >  b(204,204,204);padding-left:1ex">Synopsis: pkgin cannot identify upstream v=
 >  ersion<br>
 >  <br>
 >  State-Changed-From-To: open-&gt;closed<br>
 >  State-Changed-By: jperkin@NetBSD.org<br>
 >  State-Changed-When: Mon, 20 Apr 2020 10:50:30 +0000<br>
 >  State-Changed-Why:<br>
 >  The firefox-related parts of this PR were resolved a while back.=C2=A0 As f=
 >  or<br>
 >  the pkgin parts, you can identify the HOMEPAGE of a package using pkgin<br>
 >  with &quot;pkgin pkg-build-defs &lt;pkg&gt; | grep HOMEPAGE&quot;, and from=
 >   that be able<br>
 >  to find the source files, or grep for PKGPATH to find where all the pkgsrc<=
 >  br>
 >  related files are kept for the package in question.<br>
 >  <br>
 >  <br>
 >  <br>
 >  </blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
 >  mail_signature">George Georgalis, (415) 894-2710, <a href=3D"http://www.gal=
 >  is.org/" target=3D"_blank">http://www.galis.org/</a><br><br></div>
 >
 >  --000000000000a9ae8305a3b80df0--
 >


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

State-Changed-From-To: closed->feedback
State-Changed-By: jperkin@NetBSD.org
State-Changed-When: Mon, 20 Apr 2020 12:44:38 +0000
State-Changed-Why:
Ok, if it's true, then please be very very clear about exactly what you want,
as it is not clear at all.  You talk about "source files" vs "version configuration"
and "on the website" (what website?).  It would be helpful to provide a very concrete
example showing which parts of the package metadata are useful and which are missing,
so that we can be specific about whether pkg_summary(5) needs to be extended or not.


From: George Georgalis <george@galis.org>
To: gnats-bugs@netbsd.org
Cc: jperkin@netbsd.org, pkgsrc-bugs@netbsd.org, gnats-admin@netbsd.org
Subject: Re: pkg/47418 (pkgin cannot identify upstream version)
Date: Tue, 21 Apr 2020 22:33:31 -0700

 Alright, yes I agree, the original thread is long,
 but the ask is light and the value is high, so let
 me explain an example, and carefully recapitulate
 the request.

 In another project, the following makefile
 configuration fragment is added to the repo
 for change control. The main target builds
 complex runtime dependencies, as a bundle of
 packages, into a novel prefix. Resulting in
 low effort installation by the customer. It also
 enables reproducibility of arbitrary release
 version configurations, in delivery packaging.

 (please understand wrap, added by my email client)

 gcpapi_ver = master
 gcpapi_url_base = https://github.com/googleapis
 gcpapi_url_file = google-cloud-cpp.git
 gcpapi_url = ${gcpapi_url_base}/${gcpapi_url_file}

 gcpsdk_ver = 282.0.0-linux-x86_64
 gcpsdk_url_base = https://dl.google.com/dl/cloudsdk/channels/rapid/downloads
 gcpsdk_url_file = google-cloud-sdk-${gcloudsdk_ver}.tar.gz
 gcpsdk_url = ${gcloudsdk_url_base}/${gcloudsdk_url_file}

 Users copy ./conf/default.mk to ./conf/${conf_set}.mk
 and commit their changes. Then any user can try
 another's config, like this:
 conf_set="dev_name" make target

 The targets for each package use the conf parameters
 and are programmed to clone and checkout a branch
 (or tag), or download and extract an archive, according
 to the need and available upstream choices. Different
 programmers can independently develop different
 branch efforts, and reproduce package bundles,
 before merging configuration sets, into the default.

 On successful build and install, the target records the
 install prefix path and build version parameters, in a file
 that is parsed by components that depend on these things.

 In the end we have:
 ./conf/default.mk
 ./conf/${conf_set}.mk
 ${prefix}/install.conf

 where default.mk and ${conf_set}.mk are in version control
 and install.conf is concatenated to, as components are
 added to the prefix. The default.mk and ${conf_set}.mk files
 are included as preamble, and any target may source
 the ${prefix}/install.conf file to locate dependency
 paths. Anytime the prefix is unknown, ../install.conf
 or $(dirname "$PWD")/install.conf is helpful.

 For pkgsrc (and pkgin) I am recommending per package
 parameters such as:

 pkg_src_ver =
 pkg_src_url =
 ...etc (as reasonable per internals)

 so the specific source domain and version can be easily
 identified in a programmatic way across all packages,
 pre or post build, for planning or audit. This change
 may also simplify the patch set, when multiple packages
 must change versions together.

 I'm not suggesting a change to source download schemes,
 the request is to parametrize source uri, and create a
 uniform means to read and set these parameters.

 I hope that is clear. Uri parameterization simplifies
 agility management in other ways too. Let me know
 if I can add any clarification, or answer to a specific
 scenario.

 Thanks,
 -George



 On Mon, Apr 20, 2020 at 5:44 AM <jperkin@netbsd.org> wrote:
 >
 > Synopsis: pkgin cannot identify upstream version
 >
 > State-Changed-From-To: closed->feedback
 > State-Changed-By: jperkin@NetBSD.org
 > State-Changed-When: Mon, 20 Apr 2020 12:44:38 +0000
 > State-Changed-Why:
 > Ok, if it's true, then please be very very clear about exactly what you want,
 > as it is not clear at all.  You talk about "source files" vs "version configuration"
 > and "on the website" (what website?).  It would be helpful to provide a very concrete
 > example showing which parts of the package metadata are useful and which are missing,
 > so that we can be specific about whether pkg_summary(5) needs to be extended or not.
 >
 >
 >


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

State-Changed-From-To: feedback->closed
State-Changed-By: jperkin@NetBSD.org
State-Changed-When: Wed, 22 Apr 2020 07:04:31 +0000
State-Changed-Why:
Ok, I understand the request, but this would require completely changing
pkgsrc and all the surrounding tools, so while there could be benefits in
changing what metadata we store and the format used, completely rewriting
everything just is not practical at this time.  This kind of project is
definitely something that interested parties should pursue in a fork.


From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/47418 (pkgin cannot identify upstream version)
Date: Tue, 18 Aug 2020 09:40:29 +0000

 On Mon, Apr 20, 2020 at 12:30:06PM +0000, George Georgalis wrote:
  >  The State-Changed-Why open->closed indicates jperkin doesn't understand
  >  this request or the value of it.
  >  
  >  It would be _very_ valuable to query the actual source file used by pkgsrc
  >  (url, and revision if it is a repo), vs what is currently in use on the
  >  website.
  >  
  >  ie, the change-request is to provide a reporting of the version
  >  configuration USED by pkgsrc.
  >  
  >  This has value for research of installed packages as well as packages
  >  considered for installation.
  >  
  >  It will address the situation of a known feature or bug (per HOMEPAGE) and
  >  determination if pkgsrc is inclusive.

 Part of the problem here is that "the source file" (meaning the source
 tarball) is not a well defined concept. There are plenty of packages
 that have multiple distfiles, for various reasons, and any useful
 tracking system needs to remember _all_ of them, as well as the pkgsrc
 patches.

 The keyword you're looking for and not using, btw, is "provenance" --
 you want provenance tracking for binary packages and that's a fine
 idea, but I agree with jperkin that it's a big deal. Furthermore, you
 need a clear use case in order to determine what information you
 really need to retain; otherwise you end up collecting gigabytes or
 terabytes of completely useless metadata.

 (For example: do you need to know which compiler was used to compile
 the binary package? And if so, what about the provenance for the
 compiler? You didn't install it, you possibly don't have it, it may
 not have existed anywhere except on some buildhost somewhere, so if
 you care about that information it needs to be repeated/cutpasted into
 every output binary package, but that's a huge waste of space if you
 don't care.)

 If you're interested in building an all-singing, all-dancing binary
 package provenance tracking system, my recommendation would be to
 first figure out _clearly_ what information you want/need to collect.
 Then find some other people also interested and figure out what
 information _they_ want. tech-pkg and/or pkgsrc-users are probably
 good places for this. Then you have some chance of being able to
 hammer together a concrete proposal for _what_ data to collect, and
 then it becomes possible to start thinking about _how_.

 Keep in mind that for all this information you need to figure out how
 it manifests in the case of problem packages whose upstreams don't
 really know how to ship software, or have funny ideas, or have been
 tuned out since 2003. Asking for "the source url" is futile in
 general.

 If you aren't interested in doing all of that, my suggestion from 2013
 stands:

  : 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. 

 I'm going to leave the PR closed.

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.