Planned setup.ini changes for early 2018

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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.

Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Peter A. Castro
In reply to this post by Jon TURNEY
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
Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Achim Gratz
In reply to this post by Jon TURNEY
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
Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Jon TURNEY
In reply to this post by Peter A. Castro
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.

Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Peter A. Castro
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
Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Jon TURNEY
In reply to this post by David Stacey
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.

Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Jon TURNEY
In reply to this post by Peter A. Castro
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.
Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Achim Gratz
In reply to this post by Jon TURNEY
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
Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Achim Gratz
In reply to this post by 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
Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Jon TURNEY
In reply to this post by Achim Gratz
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/.
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Jon TURNEY
In reply to this post by 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.)
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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.

Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Jon TURNEY
In reply to this post by 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.
Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

Jon TURNEY
In reply to this post by 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
Reply | Threaded
Open this post in threaded view
|

Re: Planned setup.ini changes for early 2018

marco atzeri-4
On 01/03/2018 17:00, Jon Turney wrote:

>
> I've done this migration today.
>

Have you stopped calm schedule ?
It seem not reactive
Reply | Threaded
Open this post in threaded view
|

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