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: 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@localhost