[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: 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
> 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
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
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
If you aren't interested in doing all of that, my suggestion from 2013
: 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
Main Index |
Thread Index |