collecting information for versioned dependencies (was Re: setup -g ???)

[Jon Turney <jon dot turney at dronecode dot org dot uk>]

On 02/04/2018 18:03, Ken Brown wrote:
> [Redirected to cygwin-apps from 
> https://cygwin.com/ml/cygwin/2018-03/msg00365.html.]
>
> On 3/22/2018 6:46 PM, Jon Turney wrote:
[...]
> > This is basically correct.
> >
> > setup is now capable of being told about dependencies where upgrading 
> > an already installed package is required, but this information isn't 
> > currently collected
> >
> > (For example, some packages now exist (e.g. vim [1]), which were built 
> > with gcc 6.4.0-5 and cygport 0.31.0-1.  These packages almost 
> > certainly use ssp/fortify functions in the cygwin DLL, and so require 
> > a cygwin package >=2.10.0-1 (technically, the requirement is cygwin 
> > API >=0.320), but the dependency recorded is only on the cygwin 
> > package at any version)

(The example given is kind of incomplete, in that we could define an 
additional provides: to record that API version.)

> > That's something someone could usefully work on, if they were so 
> > inclined.
>
> The attached cygport patch attempts to address this by requiring, for 
> each dependency of a package, a version >= the version installed at the 
> time the package was built.  It treats only dependencies found by 

Thanks.  This is an interesting approach to automatically collecting 
this information I hadn't considered.

Problems are that (i) it makes package builds less reproducible (as 
these dependencies will depend on the currently installed version of 
them, which might well change over time), and (ii) it will tend of 
over-estimate the version required.

I don't know how these problems are solved in other distros, but that's 
probably worth looking at...

> cygport, not those added via REQUIRES in the cygport file.  My thinking 
> is that the cygport user should be in control of added dependencies; 
> s/he can add version numbers if desired.
>
> mksetupini would need to be updated to parse versioned dependencies. (Or 
> maybe it's expecting a different syntax; I didn't check.)