calm/mksetupini changes

calm/mksetupini changes

[Jon Turney]

I've recently deployed some updates to calm, which change a few things 
maintainers may notice:

* test: and prev: lines are no longer permitted in override.hint

Instead of test:, use the test: label in the pvr.hint to mark test 
packages (which 'cygport package-test' or 'all-test' add for you)

prev: doesn't really mean anything anymore (since setup hasn't supported 
specifically installing the prev: version since 2011 (setup version 
2.761. See [1])). keep: is a more flexible replacement.

[1] https://cygwin.com/ml/cygwin-apps/2011-07/msg00064.html

* package retention has been slightly adjusted

By default, we now retain in the relarea up to 3 non-test versions, and 
up to 2 test versions.

This can be tuned on a per-package basis using the various keep*: lines 
in override.hint. See [2]

[2] https://cygwin.com/packaging-hint-files.html#override.hint

* calm now uses a separate pvr-src.hint in the relarea

This should have no externally visible effect (e.g. generated setup.ini 
is not significantly changed), but it enables some complexity (some of 
which isn't implemented properly) to be removed from calm.

At upload, if not present, this hint is created from the corresponding 
pvr.hint by copying (if an install package also exists) or moving (if it 
doesn't) it.

I have written a patch to cygport to generate packages in this form [3], 
but that's not yet in any released cygport.

[3] https://cygwin.com/ml/cygwin-apps/2020-02/msg00050.html

In the unlikely event that:

- you have a private package repository, AND
- you run calm version >= 20200328

You'll need to successfully run 'calm-tool fix-missing-src-hint' on that 
repository before you can use calm or mksetupini.

Additionally, there have been a few other related changes:

* md5.sum files are no longer generated in the relarea.  (use the 
sha512.sum files instead)

* The '!packages' files in maintainer upload directories (which only 
exist for historical reasons, and haven't been updated for a while) have 
been removed. (The authoritative source of this information is [4])

[4] https://cygwin.com/cygwin-pkg-maint

Re: calm/mksetupini changes

[Jon Turney]

On 28/03/2020 19:26, Jon Turney wrote:
> I've recently deployed some updates to calm, which change a few things 
> maintainers may notice:

Been a while since I wrote one of these mails:

* Meaningless keys in .hint or src.hint files are now disallowed

- 'requires:' and 'obsolete:' are not allowed in src.hint files
- 'skip:' is not allowed in hint files

In the unlikely event that:

- you have a private package repository, AND
- you run calm version >= 20210626

You'll might need to successfully run 'calm-tool fix-invalid-key-hint' 
on that repository, to drop those invalid keys, before you can use calm 
or mksetupini.

* 'homepage:' is now mandatory in uploaded src.hint

(or HOMEPAGE must exist in the .cygport, if you are using a cygport so 
old it doesn't generate src.hint files)

* Upload of a 0-byte file in place of a empty compressed archive is no 
longer permitted

(cygport stopped generating such anomalies years ago)

* The 'virtual' is now allowed in 'category:', and indicates to calm 
that this package only exists to pull in other packages (i.e. is empty, 
but has dependencies, which it otherwise might warn about).

Re: calm/mksetupini changes

[Jon Turney]

On 28/03/2020 19:26, Jon Turney wrote:
>
> I've recently deployed some updates to calm, which change a few things
> maintainers may notice:

* reports are now sent to package maintainers when vaulting old 
packages, even when that's not caused by an upload (e.g. due to a change 
of test: status, or expiry policy)

* the names of packages which have been completely removed are 
remembered so they are valid to appear in obsoletes:

* packages without a maintainer are given the additional category 
'Unmaintained' in setup.ini

* package expiry refinements:

- an empty, sourceless debuginfo package, or a useless debuginfo and 
source package pair will be expired

- unused, deprecated, old shared library versions can be expired

unused: no packages depend on it (rdepends is empty)
deprecated: a later soversion exists (or the solibrary is no longer 
generated by the source package)
old: over some threshold for package age

At the moment, the package age threshold is set sufficiently high that 
no packages are selected, but I will be gradually winding it forward, to 
observe the effect on a small number of packages at a time.

Eventually, this should eliminate packages in the deprecated so report 
[1] with a rdepends count of zero.  To reduce the rdpepends count to 
zero, packages which depend on a deprecated soversion need to be rebuilt 
for a newer soversion.

[1] https://cygwin.com/packages/reports/deprecated_so.html

Re: calm/mksetupini changes

[Lemures Lemniscati]

On Sat, 21 May 2022 21:31:46 +0100, Jon Turney
> Eventually, this should eliminate packages in the deprecated so report [1] with a rdepends count of zero.  To reduce the rdpepends count to zero, packages which depend on a deprecated soversion need to be rebuilt for a newer soversion.
> 
> [1] https://cygwin.com/packages/reports/deprecated_so.html

Although libiconv2 is contained in the list above,
I don't think it is deprecated.

Maybe, libiconv package should be named as iconv
since it contains `bin/iconv.exe` and not libraries.

Lem

Re: calm/mksetupini changes

[Achim Gratz]

Lemures Lemniscati writes:
> Although libiconv2 is contained in the list above,
> I don't think it is deprecated.

I think you missed the point that Jon was trying to make: we currently
have many library packages at various versions (those with the actual
libraries) that other packages depended on at some point in time.  If
there already is a newer version of such a package and there are still
dpendencies that point to an older version, that means those packages
should eventually get rebuilt to use that newer version (if not ABI
compatible) or just use the newest version without any prodding (if ABI
compatible), which in turn means that the old versions can get removed
along with the corresponding source and debuginfo packages that were
solely kept alive by these dependencies.

In the case of libiconv2 the current version for Cygwin is 1.17-1 and
the library should be ABI compatible with all previous versions, so
these old versions up to and including 1.16-2 are deprecated since setup
will never install them unless forced manually.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: calm/mksetupini changes

[Achim Gratz]

Achim Gratz writes:
> Lemures Lemniscati writes:
>> Although libiconv2 is contained in the list above,
>> I don't think it is deprecated.
>
> I think you missed the point that Jon was trying to make

…or I missed that 1.17 is still test. :-P


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: calm/mksetupini changes

[Lemures Lemniscati]

On Mon, 23 May 2022 20:44:48 +0200, Achim Gratz
> Achim Gratz writes:
> > Lemures Lemniscati writes:
> >> Although libiconv2 is contained in the list above,
> >> I don't think it is deprecated.
> >
> > I think you missed the point that Jon was trying to make
> 
> …or I missed that 1.17 is still test. :-P

Sorry, I've not announced it yet...

Lem

Re: calm/mksetupini changes

[Jon Turney]

On 23/05/2022 14:09, Lemures Lemniscati wrote:
> On Sat, 21 May 2022 21:31:46 +0100, Jon Turney
>> Eventually, this should eliminate packages in the deprecated so report [1] with a rdepends count of zero.  To reduce the rdpepends count to zero, packages which depend on a deprecated soversion need to be rebuilt for a newer soversion.
>>
>> [1] https://cygwin.com/packages/reports/deprecated_so.html
> 
> Although libiconv2 is contained in the list above,
> I don't think it is deprecated.

Haha.  I think this is just a bug, and the code which generates that 
report is getting confused by the test: status of libiconv2.

Thanks for pointing that out.  I'll look into fixing it when I can.

> Maybe, libiconv package should be named as iconv
> since it contains `bin/iconv.exe` and not libraries.

A separate point, but yes, if we were starting from scratch that would 
probably make sense....

Re: calm/mksetupini changes

[Lemures Lemniscati]

On Mon, 23 May 2022 19:37:43 +0100, Jon Turney
> On 23/05/2022 14:09, Lemures Lemniscati wrote:
> > On Sat, 21 May 2022 21:31:46 +0100, Jon Turney
> >> Eventually, this should eliminate packages in the deprecated so report [1] with a rdepends count of zero.  To reduce the rdpepends count to zero, packages which depend on a deprecated soversion need to be rebuilt for a newer soversion.
> >>
> >> [1] https://cygwin.com/packages/reports/deprecated_so.html
> >
> > Although libiconv2 is contained in the list above,
> > I don't think it is deprecated.
> 
> Haha.  I think this is just a bug, and the code which generates that report is getting confused by the test: status of libiconv2.
> 
> Thanks for pointing that out.  I'll look into fixing it when I can.

All right. And yet another small point...

I've uploaded libiconv 1.17-1 tagged with 'test',
but their statuses are 'stable' in the page of its src package:
https://www.cygwin.com/packages/summary/libiconv-src.html ,
while the ones of generated libiconv packages are 'test':
e.g. https://www.cygwin.com/packages/summary/libiconv-devel.html .

I was confused a bit by the situation :).

Lem

Re: calm/mksetupini changes

[Jon Turney]

On 24/05/2022 11:05, Lemures Lemniscati wrote:
> On Mon, 23 May 2022 19:37:43 +0100, Jon Turney
>> On 23/05/2022 14:09, Lemures Lemniscati wrote:
>>> On Sat, 21 May 2022 21:31:46 +0100, Jon Turney
>>>> Eventually, this should eliminate packages in the deprecated so report [1] with a rdepends count of zero.  To reduce the rdpepends count to zero, packages which depend on a deprecated soversion need to be rebuilt for a newer soversion.
>>>>
>>>> [1] https://cygwin.com/packages/reports/deprecated_so.html
>>>
>>> Although libiconv2 is contained in the list above,
>>> I don't think it is deprecated.
>>
>> Haha.  I think this is just a bug, and the code which generates that report is getting confused by the test: status of libiconv2.
>>
>> Thanks for pointing that out.  I'll look into fixing it when I can.
> 
> All right. And yet another small point...
> 
> I've uploaded libiconv 1.17-1 tagged with 'test',
> but their statuses are 'stable' in the page of its src package:
> https://www.cygwin.com/packages/summary/libiconv-src.html ,
> while the ones of generated libiconv packages are 'test':
> e.g. https://www.cygwin.com/packages/summary/libiconv-devel.html .
> 
> I was confused a bit by the situation :).

Yes, this was the other half of this bug, a regression in cygport where 
the test: label wasn't correctly added to srcpkg hints.

I'll fix this data and add a consistency check to calm.

Re: calm/mksetupini changes

[Lemures Lemniscati]

On Tue, 24 May 2022 13:57:20 +0100, Jon Turney
> On 24/05/2022 11:05, Lemures Lemniscati wrote:
> > On Mon, 23 May 2022 19:37:43 +0100, Jon Turney
> >> On 23/05/2022 14:09, Lemures Lemniscati wrote:
> >>> On Sat, 21 May 2022 21:31:46 +0100, Jon Turney
> >>>> [1] https://cygwin.com/packages/reports/deprecated_so.html
> >>>
> >>> Although libiconv2 is contained in the list above,
> >>> I don't think it is deprecated.
> >>
> >> Haha.  I think this is just a bug, and the code which generates that report is getting confused by the test: status of libiconv2.
> >>
> >> Thanks for pointing that out.  I'll look into fixing it when I can.
> >
> > All right. And yet another small point...
> >
> > I've uploaded libiconv 1.17-1 tagged with 'test',
> > but their statuses are 'stable' in the page of its src package:
> > https://www.cygwin.com/packages/summary/libiconv-src.html ,
> > while the ones of generated libiconv packages are 'test':
> > e.g. https://www.cygwin.com/packages/summary/libiconv-devel.html .
> >
> > I was confused a bit by the situation :).
> 
> Yes, this was the other half of this bug, a regression in cygport where the test: label wasn't correctly added to srcpkg hints.
> 
> I'll fix this data and add a consistency check to calm.

Thank you for the fixes!

Lem