Planned setup.ini changes for early 2018

Jon Turney
Sat Jan 13 17:22:00 GMT 2018

On 12/01/2018 18:11, Peter A. Castro wrote:
> On Fri, 12 Jan 2018, Jon Turney wrote:
>> 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.
> Excellent!
>> I'm not sure what reasons there are to use older setup on a circa from 
>> after the date of this change.
> It's not quite as strange as you might think.  Older environments can't 
> necessary run newer Setup (winXP anyone? :), but, on occasion, need some 
> package from a later circa that's associated with a newer, but 
> incompatable, Setup version.  Yes, yes, I know, "don't do that".  Caveat 
> emptor and all that.


You could also use setup flag --allow-unsupported-windows in that situation.

>> I hope this means that the time machine can/will preserve depends: lines.
> It does.  'setup.ini' is preserved as originally distributed from 
> (and, of course, it's mirrors).

Oh.  I had assumed for some reason that setup.ini was regenerated for 
each circa.

Can I ask you to consider preserving the setup.ini.sig etc. as well?

>>>> * 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/.
> Thanks for the confirmation.  I'll need to make some adjustments to the 
> Time Machine for this, but should be trivial.  Do you have a schedule of 
> when you will start pushing this change out?

No schedule, but not imminent, and certainly after the other items on 
this list.

I'll let you know closer to the time.

>>> 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.
> Ok.  Thanks for confirming.  I'll watch for a mighty "gulp" in my pull 
> logs. :)
>> 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.
> What of cases where the version for x86 and x86_64 uploaded aren't the 
> same (it happens)?  Will those be skipped or am I misunderstanding how 
> this dedup process will work?

Strictly, I guess this should be disallowed, since there aren't any good 
reasons for the source packages to be different.

However, since there are suggestions that there are some packages where 
they can't be same due to shortcomings in cygport, I guess this case 
should be treated the same as currently.

More information about the Cygwin-apps mailing list