Planned setup.ini changes for early 2018

Planned setup.ini changes for early 2018

[Jon Turney]

* 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).

* 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.

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.).

* Migrate from setup.hint to pvr.hint in release area

I also plan to migrate all remaining setup.hints to pvr.hints in the 
release area (setup.hint in uploads have been automatically migrated 
since [5]).

This should have no effect on the generated setup.ini, but enables some 
complexity (some of which isn't implemented properly, see [6]) to be 
removed from calm.

[1] https://cygwin.com/ml/cygwin-apps/2017-12/msg00020.html
[2] my current implementation considers two archives identical if they 
have an identical set of members, with identical contents. Permitted 
differences include the mtime, mode or owner of members.
[3] https://cygwin.com/ml/cygwin-apps/2017-04/msg00069.html
[4] https://cygwin.com/ml/cygwin-apps/2017-05/msg00012.html
[5] https://cygwin.com/ml/cygwin-apps/2017-11/msg00044.html
[6] https://cygwin.com/ml/cygwin-apps/2017-10/msg00123.html

Re: Planned setup.ini changes for early 2018

[David Stacey]

On 10/01/18 22:44, Jon Turney wrote:
>
> * Add depends: to version descriptions
> * De-duplicate source archives
> * Migrate from setup.hint to pvr.hint in release area

That all sounds good to me.

Regarding the de-duplication of source files: will sources for 'noarch' 
packages remain in 'noarch', or will they move to 'src' as well?

Thanks to you and Ken for your work on setup.

Dave.

Re: Planned setup.ini changes for early 2018

[Jon Turney]

On 10/01/2018 23:27, David Stacey wrote:
> On 10/01/18 22:44, Jon Turney wrote:
>>
>> * Add depends: to version descriptions
>> * De-duplicate source archives
>> * Migrate from setup.hint to pvr.hint in release area
> 
> That all sounds good to me.
> 
> Regarding the de-duplication of source files: will sources for 'noarch' 
> packages remain in 'noarch', or will they move to 'src' as well?

I have no plans to do this, although I can see it is a logical next step.

Re: Planned setup.ini changes for early 2018

[Peter A. Castro]

On Wed, 10 Jan 2018, Jon Turney wrote:

Greetings, Jon,

> * 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. :)

> * 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 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).

> * Migrate from setup.hint to pvr.hint in release area
>
> I also plan to migrate all remaining setup.hints to pvr.hints in the release 
> area (setup.hint in uploads have been automatically migrated since [5]).
>
> This should have no effect on the generated setup.ini, but enables some 
> complexity (some of which isn't implemented properly, see [6]) to be removed 
> from calm.
>
> [1] https://cygwin.com/ml/cygwin-apps/2017-12/msg00020.html
> [2] my current implementation considers two archives identical if they have 
> an identical set of members, with identical contents. Permitted differences 
> include the mtime, mode or owner of members.
> [3] https://cygwin.com/ml/cygwin-apps/2017-04/msg00069.html
> [4] https://cygwin.com/ml/cygwin-apps/2017-05/msg00012.html
> [5] https://cygwin.com/ml/cygwin-apps/2017-11/msg00044.html
> [6] https://cygwin.com/ml/cygwin-apps/2017-10/msg00123.html

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: Planned setup.ini changes for early 2018

[Jon Turney]

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.

Re: Planned setup.ini changes for early 2018

[Peter A. Castro]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3907 bytes --]

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.

> 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).

>>> * 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?

>> 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?

Anyway, thanks for the awesome effort to improve distribution of Cygwin.

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: Planned setup.ini changes for early 2018

[Jon Turney]

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.

Re: Planned setup.ini changes for early 2018

[Achim Gratz]

Jon Turney writes:
> * 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).

I still think that we should revise the setup.ini syntax more thoroughly
and make a cut for setup 3.x.

> * 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.

No, please not.  Not another stupid directory tree that has more
directories than there are files.  Put these in noarch/ and arrange for
setup to be able to install both from noarch/ and $arch/ so that we can
also de-duplicate things like debuginfo and documentation down the road.

> 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.).

That isn't all that difficult to do if you could require that cygport
arranges for the same package always to be built for both architectures
(unless explicitly told otherwise) and have architecture-specific build
directories.  In the few cases where this is not possible, we can still
de-duplicate the package files without problems.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Planned setup.ini changes for early 2018

[Achim Gratz]

Achim Gratz writes:
> Put these in noarch/ and arrange for setup to be able to install both
> from noarch/ and $arch/ so that we can also de-duplicate things like
> debuginfo and documentation down the road.

I forgot to add that this is already possible by injecting extra
packages: say you deduplicate a debuginfo package into a noarch/ part
(the source files) and the $arch/ part, then you just need to inject a
dependency to the noarch package into the archful one and setup does the
right thing.  It would probably be a good idea to have a special
category for such packages in order for them to not prompt the user for
their installation.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Planned setup.ini changes for early 2018

[Achim Gratz]

Jon Turney writes:
> * 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.

You keep acting like using a new src/ hierarchy was already decided
upon, yet I don't remember it even getting discussed.  So, can we have
that discussion before decision, please?

To repeat, I think a separate src/ hierarchy would be a mistake, given
where we are today, although it has a certain appeal from a greenfield
perspective.  But more to the point, there is nothing special about
source archives (except that they're not architecture specific) that
warrants putting them into their own hierarchy, IMHO.  If they are going
to get moved on deduplication (there are good reasons to move them and
these likely outweight the benefits of just deleting them in one side of
the hierarchy), we already have a place for that and that place is
noarch/.  That keeps everything in working order for folks who for
whatever reason mirror the repository, even if the only mirror one
architecture.  If we also agree to actually move the files from a
specific architecture branch to noarch/, any mirror operator can
pre-populate the noarch/ hierarchy in order to minimize the amount of
data to get synchronized (I suggest using x86_64).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Planned setup.ini changes for early 2018

[Jon Turney]

On 13/01/2018 18:35, Achim Gratz wrote:
> Jon Turney writes:
>> * 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.
> 
> You keep acting like using a new src/ hierarchy was already decided
> upon, yet I don't remember it even getting discussed.  So, can we have
> that discussion before decision, please?

The purpose of my original email is to start that discussion.

> To repeat, I think a separate src/ hierarchy would be a mistake, given
> where we are today, although it has a certain appeal from a greenfield
> perspective.  But more to the point, there is nothing special about
> source archives (except that they're not architecture specific) that
> warrants putting them into their own hierarchy, IMHO.  If they are going
> to get moved on deduplication (there are good reasons to move them and
> these likely outweight the benefits of just deleting them in one side of
> the hierarchy), we already have a place for that and that place is
> noarch/.  That keeps everything in working order for folks who for
> whatever reason mirror the repository, even if the only mirror one
> architecture.
If I've understood correctly, your objection is that this will break 
installing source packages from mirrors which choose to mirror selected 
subdirectories (e.g. x86_64/ and noarch/).

I guess I consider that counterbalanced by the ability to selectively 
not mirror src/.

Re: Planned setup.ini changes for early 2018

[Achim Gratz]

Jon Turney writes:
> The purpose of my original email is to start that discussion.

Well, sorry then for not recognizing that, but from your other answers
in this thread I've got the impression src/ is a done deal that you
didn't want to discuss.

> If I've understood correctly, your objection is that this will break
> installing source packages from mirrors which choose to mirror
> selected subdirectories (e.g. x86_64/ and noarch/).

My personal objection is that it will add another two hours to mirroring
the Cygwin repo via a HTTP proxy (or I just give up on mirroring the
sources).  But yes, not breaking things for folks who try to be nice to
mirror operators is next on my list.  Then come the mirror operators
themselves.  I must admit I hadn't considered the Cygwin Time Machine,
this adds another twist that I haven't fully thought through yet.

> I guess I consider that counterbalanced by the ability to selectively
> not mirror src/.

I don't, due to the conspicUous naming of the source archive files that
effect is easily achieved by all mirroring methods that I have
personally used.  So it doesn't really add any value that I can see to
counterbalance the other ripple effects it will have.

Unfortunately I don't have a lot of time on my hands right now, but I
think (very preliminarily) that aside from keeping the directory
structure intact, we should also keep the old setup.ini as-is (not just
compatible) and instead move the "new" setup.ini one level up and have
it encompass both supported architectures using a more compact syntax.
It should be possible to generate the "old" x86{,_64}/setup.ini by
transforming the "new" setup.ini so you can hopefully drop some more
baggage in calm.  The main benefit of using a modified format would be
to not have the redundant information in it as the current format would
need to carry.  As long as we keep the old format around that redundancy
is effectively still with us, but we can isolate it more easily.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Planned setup.ini changes for early 2018

[Jon Turney]

On 10/01/2018 22:44, 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).

On further testing, it's not safe to expose some versions of setup to 
'depends:' lines, so these will have to be called 'depends2:' or 
suchlike, so they are safely ignored.

(The dependencies of the current version are always used, not the 
version actually being installed, so it may install incorrect 
dependencies if a non-current version is installed, potentially 
resulting in a broken package.)

Re: Planned setup.ini changes for early 2018

[Achim Gratz]

Jon Turney writes:
> On further testing, it's not safe to expose some versions of setup to
> 'depends:' lines, so these will have to be called 'depends2:' or
> suchlike, so they are safely ignored.

Could you at least consider my earlier proposal to leave the old-style
setup.ini separate to entirely avoid that problem and the associated
chatter in those files?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Planned setup.ini changes for early 2018

[Jon Turney]

On 23/01/2018 18:30, Achim Gratz wrote:
> Jon Turney writes:
>> On further testing, it's not safe to expose some versions of setup to
>> 'depends:' lines, so these will have to be called 'depends2:' or
>> suchlike, so they are safely ignored.
> 
> Could you at least consider my earlier proposal to leave the old-style
> setup.ini separate to entirely avoid that problem and the associated
> chatter in those files?

I considered a few approaches, including what you suggest.

This approach is more work, and a lot of churn, in both setup and calm. 
The only additional benefit you've identified is removing clutter.

Re: Planned setup.ini changes for early 2018

[Achim Gratz]

Jon Turney writes:
> I considered a few approaches, including what you suggest.
>
> This approach is more work, and a lot of churn, in both setup and
> calm. The only additional benefit you've identified is removing
> clutter.

Well, it'd give you a clean slate to start from and the transformation
to the old-style setup.ini files would be an easy post-processing step
that'd be independent of the main work of calm (either a text
transformation or a second output pipeline).  But I understand you've
made up your mind, so I'll stop trying to come up with a concrete format
proposal for a new-style setup.ini, at least at this time.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Planned setup.ini changes for early 2018

[Jon Turney]

On 22/01/2018 23:13, Jon Turney wrote:
> On 10/01/2018 22:44, 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).
> 
> On further testing, it's not safe to expose some versions of setup to 
> 'depends:' lines, so these will have to be called 'depends2:' or 
> suchlike, so they are safely ignored.

I deployed a calm update today which adds this header to the generated 
setup.ini

This should be ignored by all currently released setup versions.

Re: Planned setup.ini changes for early 2018

[Jon Turney]

On 10/01/2018 22:44, Jon Turney wrote:
> 
> * Migrate from setup.hint to pvr.hint in release area
> 
> I also plan to migrate all remaining setup.hints to pvr.hints in the 
> release area (setup.hint in uploads have been automatically migrated 
> since [5]).
> 
> This should have no effect on the generated setup.ini, but enables some 
> complexity (some of which isn't implemented properly, see [6]) to be 
> removed from calm.

I've done this migration today.

At some point in the future calm/mksetupini will stop supporting 
setup.hints in the release area. (calm will still accept and migrate 
uploads containing a setup.hint, as per [1])

So, for the record, if you have an up-to-date calm installed, this 
migration can be done with 'calm-tool hint-migrate [--releasearea=...]'

[1] https://cygwin.com/ml/cygwin-apps/2017-11/msg00044.html

Re: Planned setup.ini changes for early 2018

[Marco Atzeri]

On 01/03/2018 17:00, Jon Turney wrote:

> 
> I've done this migration today.
> 

Have you stopped calm schedule ?
It seem not reactive

Re: Planned setup.ini changes for early 2018

[Jon Turney]

On 01/03/2018 16:39, Marco Atzeri wrote:
> On 01/03/2018 17:00, Jon Turney wrote:
> 
>>
>> I've done this migration today.
>>
> 
> Have you stopped calm schedule ?
> It seem not reactive

calm was stopped between 02:00 and 15:45 UTC today.

Your postgres upload has been processed, but no email was sent (because 
I had calm emails turned off while doing some checks, and I didn't 
notice that upload was pending)

Sorry for the inconvenience.

Re: Planned setup.ini changes for early 2018

[Jon Turney]

On 01/03/2018 16:00, Jon Turney wrote:
> On 10/01/2018 22:44, Jon Turney wrote:
>>
>> * Migrate from setup.hint to pvr.hint in release area
>>
>> I also plan to migrate all remaining setup.hints to pvr.hints in the 
>> release area (setup.hint in uploads have been automatically migrated 
>> since [5]).
>>
>> This should have no effect on the generated setup.ini, but enables 
>> some complexity (some of which isn't implemented properly, see [6]) to 
>> be removed from calm.
> 
> I've done this migration today.
> 
> At some point in the future calm/mksetupini will stop supporting 
> setup.hints in the release area. (calm will still accept and migrate 
> uploads containing a setup.hint, as per [1])

I recently deployed this change, so in the unlikely event that:

- you have a private package repository, AND
- it contains some packages which are old enough to have a setup.hint

You'll need to successfully run 'calm-tool hint-migrate' on that 
repository before you can use calm >= 20190530.

> So, for the record, if you have an up-to-date calm installed, this 
> migration can be done with 'calm-tool hint-migrate [--releasearea=...]'
> 
> [1] https://cygwin.com/ml/cygwin-apps/2017-11/msg00044.html