Re: Planned setup.ini changes for early 2018

[Jon Turney <jon.turney@dronecode.org.uk>]

On 11/01/2018 17:53, Peter A. Castro wrote:
> On Wed, 10 Jan 2018, Jon Turney wrote:
>> * Add depends: to version descriptions
>>
>> This is a version-specific list of required packages (as opposed to 
>> requires:, which is per-package, and contains the union of the 
>> dependencies for all versions).
>>
>> I believe that historical setup versions will either ignore, or can 
>> handle depends: (just containing package names, without version 
>> relations) relatively sanely (see [1] et seq. for details).
> 
> As long as the behaviour you outline in [1] is consistent, then that 
> means I should be able to use older Setup with newer setup.ini, yes?  
> That will be useful for people who use the Time Machine. :)

Yes, this doesn't break backwards compatibility.

I'm not sure what reasons there are to use older setup on a circa from 
after the date of this change.

I hope this means that the time machine can/will preserve depends: lines.

>> * De-duplicate source archives
>>
>> Source archives which are identical[2] between x86 and x86_64 will be 
>> moved to paths starting src/ in the release area.
> 
> I'm not quite visualizing this,  Do you mean there will be a new 
> directory name 'src' that will be on the same level as 'x86' and 
> 'x86_64' or will it be higher up the directory tree?  It matters to me 

This means src/ on the same level as x86/ x86_64/ and noarch/.

> for the Time Machine as I'll need to be able to re-create the same 
> directory hierarchy for each circa.  It's a selectively automated 
> process currently, but I need to know what symlink to place where.  :)
> 
>> Doing post-hoc de-duplication is unfortunate, but worthwhile given the 
>> potential size saving in mirrors (see [3] et seq.), until cygport can 
>> be taught how to make suitable source packages (which has several 
>> unresolved issues, also discussed at [3], [4] et seq.).
> 
> Will this be done en masse upon the next setup.ini build cycle, or over 
> time as each new package is updated?  Having a massive amount of "new" 
> packages show up under a "new" directory named 'src' will be quite a lot 
> for the mirrors to absorb all at once.  For the Time Machine it might 
> effectively be double as I have to maintain the old hierarchy as well as 
> the new one (under the assumption that you'd apply the de-duplication 
> retroactively).

The process will be gradual and retroactive.

I'm not quite sure yet how it's going to apply to new uploads.  Often 
x86 and x86_64 packages are uploaded separately, so either it happens 
asynchronously, after the last upload of the pair has been accepted, or 
I defer accepting and deduping the upload until both are uploaded.