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

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

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/