Re: pkg/47418 (pkgin cannot identify upstream version)

[George Georgalis <george%galis.org@localhost>]

The following reply was made to PR pkg/47418; it has been noted by GNATS.

From: George Georgalis <george%galis.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: jperkin%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost
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@localhost> wrote:
 >
 > Synopsis: pkgin cannot identify upstream version
 >
 > State-Changed-From-To: closed->feedback
 > State-Changed-By: jperkin%NetBSD.org@localhost
 > 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/