This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Planned setup.ini changes for early 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.

Ok.

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 cygwin.com (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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]