On Sat, 2024-10-05 at 12:31 +0200, Simon Josefsson wrote:
[...]

This will rename the binary package to 'signify-mail', as suggested in
the first bug report above, and add a 'signify (<< 1.14-8~)' Replaces
header.

Is anything more required here?

[...]

Yes, I think you should also rename the source package signify.

Debbugs doesn't always properly distinguish source and binary package
names. This goes badly when there are a source and binary package of
the same name, but the binary package is built by a different source
package.

And of course, a situation like that is also confusing to humans.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmcBZBcACgkQ57/I7JWG EQla2hAArMpmRWKL4AzNUtKvSJhMVotVG3pI6Qh6VtFOshbbkzFZ71PDuW7vfgJV hbwq4q7J13ht2jzp8LuhqwKfnxndSiMoEl5XB7v5SUebScDxAnpjWFXwpXn7CPHY BBN2MytFT6dVwXFSR8FkUep2KcKnBnUtqkBYnYxHVbSZ4c396TBLtijXHFiUbcJt Ek6uJhLbORQMBWbhKmDFsgOwXZrt5J2MdjUlWoAKyuBVgO2t4PLlgwEbkT4eLZF+ hVZNxXAzzRqGoW8HSfkVU9xKxCu63qKFNzt3BMbvUsmxstRY6Bs/8QJvkPX4N49M miNjOSxgAoSX1xVk2je5hh9ayyIaE9N7YLU08WT77FcqxrsoBnxzZQa25RRooHop nXoEBOWcJ4d12g5mmCQ2MTrtDFEZq+9h3resSSYISCWOf8JJpVS7n0pQ/+LL3zR8 8b47koZJT3XHPvsRlI1psddGO4RZcUggwVy6iL/IJs1P8vhGj1LVABt2U1Bb7ubw 6EiO35NsccV/AsujrbO+O9nVTKc7dVb0mcUUw78U2rMP4GyaY/HcXuSPBr1bzZ3F FL3w2mLfd1eSCvpdz+dFZ5zQ8He5A6/F+GzTAtimR+QRBE3UU+YF+NQjAKygqfXG VEYxKbMP6pU3bERqyJFA5RLc1K5TlaXrfW045pDQkph0ANnAgcs=
=KVvY
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ben Hutchings <ben@decadent.org.uk> writes:

On Sat, 2024-10-05 at 12:31 +0200, Simon Josefsson wrote:
[...]

This will rename the binary package to 'signify-mail', as suggested in
the first bug report above, and add a 'signify (<< 1.14-8~)' Replaces
header.

Is anything more required here?

[...]

Yes, I think you should also rename the source package signify.

I think that would be nice from a human namespace perspective but I
don't know if Debian have any documented process for doing that. Can
anyone find a pointer to relevant documentation? What is the process?
Upload 'signify' to NEW again as 'signify-mail', and then ask for
removal of the 'signify'? Can the source package name then be re-used
by 'signify-openbsd'? Or is there a rename operation policy, asking for 'signify' to be renamed to 'signify-mail', and 'signify-openbsd' renamed
to 'signify'? Doing renames is confusing for a long-term perspective,
how is that piece of meta-information recorded and where? Is there any
earlier examples of a source package rename?

Debbugs doesn't always properly distinguish source and binary package
names. This goes badly when there are a source and binary package of
the same name, but the binary package is built by a different source
package.

And of course, a situation like that is also confusing to humans.

+1

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZwGCLhQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFov1LAQC/NacfM0k6mh4boOOsR1XWJP/ykKDV 9v510PJ3CNG8fAEA4ttofoROMlFDbZ/lORf61Swj53Ki4/4WVVKuuxDQQAc=kj4K
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2024-10-05 at 20:15 +0200, Simon Josefsson wrote:

Ben Hutchings <ben@decadent.org.uk> writes:

On Sat, 2024-10-05 at 12:31 +0200, Simon Josefsson wrote:
[...]

This will rename the binary package to 'signify-mail', as suggested in the first bug report above, and add a 'signify (<< 1.14-8~)' Replaces header.

Is anything more required here?

[...]

Yes, I think you should also rename the source package signify.

I think that would be nice from a human namespace perspective but I
don't know if Debian have any documented process for doing that.

I am not aware of one.

Can
anyone find a pointer to relevant documentation? What is the process?
Upload 'signify' to NEW again as 'signify-mail', and then ask for
removal of the 'signify'? Can the source package name then be re-used
by 'signify-openbsd'?

I believe that should work. You would also ask for removal of the 'signify-openbsd' source package at the end of the process.

Or is there a rename operation policy, asking for
'signify' to be renamed to 'signify-mail', and 'signify-openbsd' renamed
to 'signify'?

I'm fairly sure there's no support for this in Debian infrastructure
(dak or debbugs).

Doing renames is confusing for a long-term perspective,
how is that piece of meta-information recorded and where? Is there any earlier examples of a source package rename?

[...]

It's recorded in the changelog and, so far as I know, nowhere else.

In 2012 the linux-2.6 source package was renamed to linux. It had to
go through NEW, but that was needed for every ABI bump anyway. We had
to track bugs against both source package names for several years
(until EOL of the last release with linux-2.6).

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmcBh+sACgkQ57/I7JWG EQkM4Q//XRNTNmHtfg5qLYmLNtC60/Mb+Q2nFy2jbi95LIRmTq4jZ1rhdq5hsGQu aoQ3MbGYx6PZH6MZsl48PuP82BCkEjRiyiqIMgTk3HAkdmVeyx4eFjkyBrnuUvsU 6Am1JxTf2qkAHjOv4qpSAqSXen27MUZRXWc9lYye3LqjBkMOXvREgMrWp88N/a3y 0jq2vE3GQVIyJLxZp4sRFal2r96GVVIU0o3kK9RULTAw+SVOHCLHGvpx5SNytVcE 4jN3uFfQi0zcMIvbes9WgWb6oQ1IvI8jnPLoCw+KLYHVKKMu3Ay4wPSZEBNyJxQR W/aJ2iCUc1qIgZjgMfNzRezmnJgjl6euIPz+/ryOtGA+7a7kzmGXT3oJI4lTPLuf SLmuwbEpPBeuQcWtfG/puzTqF7rP4m6KMnCJGB0rWKid0DCrqvYZDE2lj2cTag3U qq0FDvxUCDkQzXZ62IBcgZQ7jGOQmg8swSP9vuC38y2L13lrcdYQdaivs4aUIMic yPr99Wq0y9wKhwIimmlckbqMrh5ef2vVYh0umuoQ0ib8A7iaAs1/2GIi5SyfTeFL wQfRlz0e9eNYGcreUriqAcDOt2VlHu3rtHTNQs9c3xevxk4lKgZhlBAFhi5vY84f OBh3u5TX6+a35EFp5a2pmavf4HUZ5l0hMatUClBCVAYlECx9a4s=
=YsUT
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ben Hutchings <ben@decadent.org.uk> writes:

On Sat, 2024-10-05 at 20:15 +0200, Simon Josefsson wrote:

Ben Hutchings <ben@decadent.org.uk> writes:

On Sat, 2024-10-05 at 12:31 +0200, Simon Josefsson wrote:
[...]

This will rename the binary package to 'signify-mail', as suggested in >> > > the first bug report above, and add a 'signify (<< 1.14-8~)' Replaces
header.

Is anything more required here?

[...]

Yes, I think you should also rename the source package signify.

I think that would be nice from a human namespace perspective but I
don't know if Debian have any documented process for doing that.

I am not aware of one.

Can
anyone find a pointer to relevant documentation? What is the process?
Upload 'signify' to NEW again as 'signify-mail', and then ask for
removal of the 'signify'? Can the source package name then be re-used
by 'signify-openbsd'?

I believe that should work. You would also ask for removal of the 'signify-openbsd' source package at the end of the process.

Or is there a rename operation policy, asking for
'signify' to be renamed to 'signify-mail', and 'signify-openbsd' renamed
to 'signify'?

I'm fairly sure there's no support for this in Debian infrastructure
(dak or debbugs).

Doing renames is confusing for a long-term perspective,
how is that piece of meta-information recorded and where? Is there any
earlier examples of a source package rename?

[...]

It's recorded in the changelog and, so far as I know, nowhere else.

In 2012 the linux-2.6 source package was renamed to linux. It had to
go through NEW, but that was needed for every ABI bump anyway. We had
to track bugs against both source package names for several years
(until EOL of the last release with linux-2.6).

I agree in principle, but I wonder if going through the effort of
introducing a new source package 'signify-mail' and removing the current 'signify' will give us anything beyond doing the QA package upload to
rename the binary package.

The only advantage I can identify seems to be if the 'signify-openbsd'
source package would then be able to be renamed to 'signify'. But is
that possible? Are there any earlier examples of re-use of the same
source package name, but for a different package? The linux-2.6 vs
linux analogy is not identical, it is the same source package and there
were no source package namespace re-use happening.

This all assumes Tomasz as maintainer is interested in renaming his 'signify-openbsd' to 'signify'.

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZwJADhQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFosTqAQCoU2YruC56XVKbnyz/u8MPTtP+67eb 8D3EF4gmR/KjCAEA/HFlu1Eez70rBJ9TyQrnfF5N2Uina6WizzEgVpf7tQM=w/wt
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marco d'Itri <md@Linux.IT> writes:

On Oct 05, Simon Josefsson <simon@josefsson.org> wrote:

I would like that 'apt install signify' install OpenBSD's signify (from
the Debian 'signify-openbsd' package) and not the 2003 mail-related
signify perl script from the Debian 'signify' source package.

Agreed: the current signify package is a niche tool maintained by QA and
last updated upstream in 2004: it should be renamed without wasting any
more time.

To make this happen for trixie, I don't see how to do it. Anyone having
the old 'signify' package on their system would get OpenBSD's signify
instead of the new 'signify-mail' package after an upgrade. Is that
problem really worth caring about?

No: popcon == 58.

although small, the benefit also seems small. and 58 also seems like a
lot of people who might be inconvenienced?

could better be done with metapackages over 2 stable releases?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-10-06 Simon Josefsson <simon@josefsson.org> wrote:
[...]

I agree in principle, but I wonder if going through the effort of
introducing a new source package 'signify-mail' and removing the current 'signify' will give us anything beyond doing the QA package upload to
rename the binary package.

The only advantage I can identify seems to be if the 'signify-openbsd'
source package would then be able to be renamed to 'signify'. But is
that possible? Are there any earlier examples of re-use of the same
source package name, but for a different package? The linux-2.6 vs
linux analogy is not identical, it is the same source package and there
were no source package namespace re-use happening.

[...]
Hello Simon,

Afaiu Ben gave the rationale in his initial mail:
| Yes, I think you should also rename the source package signify
|
| Debbugs doesn't always properly distinguish source and binary package
| names. This goes badly when there are a source and binary package of
| the same name, but the binary package is built by a different source
| package.

If you do not rename signify(src) to signify-mail(src) the bts might mix
up bugs against signify(bin) from signify-openbsd(src) with bugs against
the source package signify.

Renaming signify-openbsd(src) to signify(src) was *not* suggested.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-10-06 17:45:46 +0200 (+0200), Andreas Metzler wrote:
[...]

If you do not rename signify(src) to signify-mail(src) the bts might mix
up bugs against signify(bin) from signify-openbsd(src) with bugs against
the source package signify.

Renaming signify-openbsd(src) to signify(src) was *not* suggested.

Yes, in the past (granted it's been years/decades), when I was
looking at a takeover for an old source package name, the prevailing
guidance was to make sure the old source package was removed for at
least a full Debian release before introducing the replacement, but
ideally wait until all versions for old Debian releases had
completely aged out of the pool (these days I guess that would
include waiting for LTS versions to no longer include it as well?).
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmcCt1ZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCmL/Q//RxX0NUmjca6fumEfheZV1DuBhKALsko9CSKCEq6dfJ9a3WLdrX0//wEp pPt1Ra197lzaZ2nc3yhxWB5OyRHYPL1/djAZLQC+oeBSezhDGE2uSNfb0Sy0DH1d +oYTf+LnVwvizqZmNCqZmYs0RQXsgJmbOEycg6Sa78q10VlojalwPK8AH7FmSulJ y1DdVzFMeT38RZhERkcBeSOU4WErt2a3BlzhXMJ2f9mqpG0xwWemuU9r9usdN4/C mZdwc01TqebmU5bVGU5IYx9eJvGOHBvC8mufz26iM9sc+tF36i3l22NrHaID25FW /Lo+r7CjJixH//5/nw1beiQrgIsEg0m8bMWbS2dzLBT7cLp0nByFpVm0nJGI+/tw WJsWHO9/XiiYZ+aiMdzrDpO9jI+lMw3yDXOWbmUNPcaFeEAILl0AjvYh/OPzD42t eymnVux52hxQzv8md7l/hTASb2jS7Ck/L7nLpScN4KC+hga12wIAhmLtP3Y+G+bl wyXsYVEImwLNFuyQksW8C8SmCtPebRSU4pE6/X8yy+IrD50BlDW4SPisU3ki4xmw EYJq7SEMDQ7vhTy339+CP2/dRLkDpY/zAKFSrscidezW8phxPMgaCxS+rioq9Y3+ 4io87LWyEv1qcw5aEv63GhOnwcFBxEy8gr/RPP4fgCM6YncVkqA=
=6mrF
-----END PGP SIGNATURE-----

--- SoupGate-Win32

On Sun, 2024-10-06 at 17:45 +0200, Andreas Metzler wrote:

On 2024-10-06 Simon Josefsson <simon@josefsson.org> wrote:
[...]

I agree in principle, but I wonder if going through the effort of introducing a new source package 'signify-mail' and removing the current 'signify' will give us anything beyond doing the QA package upload to rename the binary package.

The only advantage I can identify seems to be if the 'signify-openbsd' source package would then be able to be renamed to 'signify'. But is
that possible? Are there any earlier examples of re-use of the same
source package name, but for a different package? The linux-2.6 vs
linux analogy is not identical, it is the same source package and there were no source package namespace re-use happening.

[...]
Hello Simon,

Afaiu Ben gave the rationale in his initial mail:

Yes, I think you should also rename the source package signify

Debbugs doesn't always properly distinguish source and binary package names. This goes badly when there are a source and binary package of
the same name, but the binary package is built by a different source package.

If you do not rename signify(src) to signify-mail(src) the bts might mix
up bugs against signify(bin) from signify-openbsd(src) with bugs against
the source package signify.

Renaming signify-openbsd(src) to signify(src) was *not* suggested.

I think it's reasonable to do that too, though it is less important.

Ben.

--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmcCt9cACgkQ57/I7JWG EQmt/RAAxIXvL6mSnBVsIcSObb7tBgXVTbdGJ4vlYHdORFjcfUnR56hAyKjrNb0m b84erBr0ZZfGQk+EyEUx4gMBStJSiaX5wTl3uhP6eXYQUZiBxdlh4aZKfYsuTsgI eauOqrbizBV5yc1dT0QDcfFzZDWnmKMuZlQvkujs8cxt6vU/3REuJeqVsjGe7Zlu 7TzI13fhYbu35tb5G7i05kkZGdSp15aQ/rOzqpf3t45pqjMQgKAxr6jREFlo6GYt FpQjOlx0l3wvRFZgVkLsmC7wQ2nvbG8rANbfqUQ5jtz8GHjPOxxSRt0lW7ylgtdU ZYzGNC6+ovnJkrUrZk4MhyZQQlyl9P8dXZoQPe/kUfBgAy4k7aqoYglNodies3nk Um9evSaUnERVQyRnqDOSm0BND1Xeb2GExOwIIbO4uz2bCCfkv2KtC+tiuslXSWY0 POjruxmz4wlOeKp2Pa47ayYs3yeqw5cAn2b+f9z/sjSAJzPqRfs+e2QF9QeN9XSx UaCEBmbl7++EJMj6m9bxgKYD8DH8CEoEqZg7yAb7mnNEcZsveP1nMvL2aQ1ZPMa8 bCk01z12xqnVj1y1O8bw6dIG5EIEdGg5FFG8doA+itFP8H/AvTSpqLCW0OCmBysI 9xHz7F4z832yMY8k9VR4bnxY+WGXnFpavuLjuFamjCSGKp6TOrA=
=/dSm
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2024-10-06 at 09:45 +0200, Simon Josefsson wrote:
[...]

I agree in principle, but I wonder if going through the effort of
introducing a new source package 'signify-mail' and removing the current 'signify' will give us anything beyond doing the QA package upload to
rename the binary package.

The only advantage I can identify seems to be if the 'signify-openbsd'
source package would then be able to be renamed to 'signify'. But is
that possible? Are there any earlier examples of re-use of the same
source package name, but for a different package?

[...]

There are 2 prominent examples:

- chromium (the original chromium is now chromium-bsu)
- git (the oriignal git is now gnuit)

Ben.

--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmcCt4MACgkQ57/I7JWG EQkMyRAAv6o0d7rb915qO7MDSYHf6h6o7qH7nv8NafAqo5i5hNY8iQcJaBGJ98+q vHpHA3sZ8JUigUsE3mZ3WwEBrxk0SQ8gkLjoIs7e3jOw6kaOQqPPHpG8i3gfesqO oxcECgBYMt0xO9xnvR3QZJjei6QI4ju9bbTjHmYdxLLcXU+H2QtoF3Ei3F0qJNCr kLDyq60d/vL9xMUBaDqAPrSG6wZfWToIy0m5QsUhqCjhIDfnrLC6t4nxOnnpQvY+ tpIbCFBUmapQaxjS6eG5eMpXeOONX0iFvRPNyrRYk1pj4wlR6YoW7momQTQgDn6b jeL2MRH6ama3vqEGAKbEX9ZzhB67RNaggXcw3TURu45hb0i47AVg/7gUGqMLBkX0 l4Unl6PwstXCOJInNp5zJ6S89aw+ovBvtD7Q8bJielnahvmC30PYiCc30kFF+vPY +dDzFqK+UfL63a4e2D11jgUQL4CxlOI6A24rRwmexFSNXmpEQmLZlN1D5jbb8obb 73w9ZpwsKRz48CdPD0etxt8k/8qVA7RMW5tfMfReLdWqowOKL+89BL0TxpEDRwFW zLFYY0jN9m07cOeseCj/UEcG0rEmMmQ4DcFfj9XT9dWs/r8FCg//dNZHulPUdhRX 1g8u5LDzBVgrFmN/KptgEg45tsgW6iVvu94aVRUJYE/WyHxKMLE=
=ikvc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun Oct 6, 2024 at 4:45 PM BST, Andreas Metzler wrote:

If you do not rename signify(src) to signify-mail(src) the bts might mix
up bugs against signify(bin) from signify-openbsd(src) with bugs against
the source package signify.

Do we know in which direction the problem might occur? signify(src) has
only ever had 15 bugs (of which only one is open and unarchived).

Is the problem well understood enough that debbts could potentially be
fixed?

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 05 Oct 2024 20:39:39 +0200, Ben Hutchings
<ben@decadent.org.uk> wrote:

I'm fairly sure there's no support for this in Debian infrastructure
(dak or debbugs).

I have the gut feeling that this is going to cause at least minor
discomfort because our tools don't care for that at all. I still get
occasional mail for a package that is no longer mine: I had mine
removed from the archive a decade ago, and the package name was since
reused for a different package, and still I get occasional mail
concerning the new package.

I also see trouble in the archive when we have old signify in older distributions and new signify in unstable and testing. Without having
any technical justification for that, I would probably go ahead to
rename signify to signify-mail, leaving signify-openbsd named that way
until the old signify source package has aged out of the archive
completely and was moved to archive.d.o.

Greetings
Marc

P.S.: Isnt it about time to rename exim4 to exim?
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 10/7/24 16:58, Marc Haber wrote:

I also see trouble in the archive when we have old signify in older distributions and new signify in unstable and testing. Without having
any technical justification for that, I would probably go ahead to
rename signify to signify-mail, leaving signify-openbsd named that way
until the old signify source package has aged out of the archive
completely and was moved to archive.d.o.

The correct approach is one release with a transitional package, pulling
the new package in, and one release with the name unused (so the
transitional package is listed in Obsolete/Local).

The release without the package also makes sure that any archive version constraints (oldstable < stable, stable < testing, testing < unstable)
are satisfied even if testing < oldstable.

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 7 Oct 2024 17:31:33 +0900, Simon Richter <sjr@debian.org>
wrote:

On 10/7/24 16:58, Marc Haber wrote:

I also see trouble in the archive when we have old signify in older
distributions and new signify in unstable and testing. Without having
any technical justification for that, I would probably go ahead to
rename signify to signify-mail, leaving signify-openbsd named that way
until the old signify source package has aged out of the archive
completely and was moved to archive.d.o.

The correct approach is one release with a transitional package, pulling
the new package in, and one release with the name unused (so the
transitional package is listed in Obsolete/Local).

I was actually talking about source package names, not binary.

Greetings
Marc
--
---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Simon Richter <sjr@debian.org> [241007 04:32]:

The correct approach is one release with a transitional package, pulling the new package in, and one release with the name unused (so the transitional package is listed in Obsolete/Local).

The release without the package also makes sure that any archive version constraints (oldstable < stable, stable < testing, testing < unstable) are satisfied even if testing < oldstable.

Let me see if I understand what you are saying.

trixie:
remove old src: signify

single source upload:
src: signify -> signify-mail
binary: signify -> signify-mail
new signify as transitional
unversioned Depends: signify-mail

trixie+1:
remove transitional binary signify

trixie+2:
rename binary signify-openbsd -> signify
Is the following necessary?
versioned Conflicts: signify <= version of transitional signify in trixie
version of this signify must be > version of old transitional pkg

I believe that renaming the source from signify-openbsd to signify has
very little benefit. What most users are going to see is the binary
package. Anyone searching for the source package generally has enough knowledge of Debian to find the correct source. Leaving the source name clearly distinguishes it from the old source.

...Marvin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 10/7/24 21:43, Marvin Renich wrote:

trixie:
remove old src: signify

yes.

single source upload:
src: signify -> signify-mail
binary: signify -> signify-mail
new signify as transitional
unversioned Depends: signify-mail

yes.

trixie+1:
remove transitional binary signify

yes.

trixie+2:
rename binary signify-openbsd -> signify
Is the following necessary?
versioned Conflicts: signify <= version of transitional signify in trixie

no, because the new package has the same name as the old transitional
package and thus implicitly conflicts, also the old package should not
be installed anymore.

version of this signify must be > version of old transitional pkg

not strictly necessary (that's why we leave one release gap in between).

This is a gap in the frontend software though: we have very little UI to
guide people into uninstalling transitional packages -- basically
aptitude showing them in a separate section is the strongest there is.

We also don't have any UI (not even in aptitude -- #990118) to inform
people that they have packages installed that exist in the archive but
they will not receive any upgrades for because their local version is newer.

I believe that renaming the source from signify-openbsd to signify has
very little benefit. What most users are going to see is the binary
package. Anyone searching for the source package generally has enough knowledge of Debian to find the correct source. Leaving the source name clearly distinguishes it from the old source.

I'd expect the archive to enforce

oldstable < stable && stable < testing && testing < unstable

for source package versions as well, so if the new package's version
number is higher than the old one's, it can be done in one release,
otherwise it needs two. Not sure how the archive would react if
oldstable and testing have the same version number but different
packages. :P

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Simon Richter <sjr@debian.org> [241007 09:50]:

On 10/7/24 21:43, Marvin Renich wrote:

trixie:
remove old src: signify

yes.

single source upload:
src: signify -> signify-mail
binary: signify -> signify-mail
new signify as transitional
unversioned Depends: signify-mail

yes.

trixie+1:
remove transitional binary signify

yes.

trixie+2:
rename binary signify-openbsd -> signify

But yes to the above?

Is the following necessary?
versioned Conflicts: signify <= version of transitional signify in trixie

no, because the new package has the same name as the old transitional
package and thus implicitly conflicts, also the old package should not be installed anymore.

version of this signify must be > version of old transitional pkg

not strictly necessary (that's why we leave one release gap in between).

Thanks for clarifying.

...Marvin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Attempting to summarize this thread into actions - please correct me
when I misunderstood:

1) Take current non-OpenBSD 'signify' source package and upload NEW 'signify-mail' with d/control modified as:

Source: signify-mail
...
Package: signify-mail
Replaces: signify (<= 1.14-7)

Do we need 'Breaks: signify (<= 1.14-7)' too? Conflicts?

I've re-read chapter 7 of the policy manual again, but I have read it so
many times before and still don't feel confident about what it actually
means. https://www.debian.org/doc/debian-policy/ch-relationships.html

2) Once 'signify-mail' has entered testing, open a ftp.debian.org RM bug
for 'signify' to get the binary packages removed from testing.

3) Open a wishlist bug for 'signify-openbsd' with a patch to provide a 'Package: signify' that has /usr/bin/signify and to add:

Conflicts: signify (<= 1.14-7), signify-mail

Is a similar Breaks needed too?

The 'signify-openbsd' binary package should be left around as a empty
dummy package for transitions to the new 'signify' binary package.

4) Uploading source package 'signify-openbsd' to NEW as 'signify', and
then ask for removal of the old 'signify-openbsd' source package. This
is nice but optional. It was suggested this can trigger BTS bugs. It
may be best to wait until at least trixie+1. This doesn't affect users
so is more of an developer aesthetic concern, which may suggest it isn't
worth doing at all.

/Simon

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZwTYshQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFogazAP4qsqTDEabQ5/USiuBwo4nkiYsUHHxE IXEuyStMLk6A/wEAvWGEV0uWvqPMkYA+M6bhO0OEJly9FFRvBuqIwEs4DA0=
=VFH6
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 10/8/24 16:01, Simon Josefsson wrote:

1) Take current non-OpenBSD 'signify' source package and upload NEW 'signify-mail' with d/control modified as:

Source: signify-mail
...
Package: signify-mail
Replaces: signify (<= 1.14-7)

Do we need 'Breaks: signify (<= 1.14-7)' too? Conflicts?

Conflicts, yes.

The Replaces+Conflicts combination is interpreted in a special way,
because normally it would be nonsensical: two packages cannot be
installed at the same time, but if they are, files from one take
precedence. So this is how to encode that one package should completely
replace another.

The overlap in files is not 100%, but that is fine, both apt and dpkg
know what to do.

The Conflicts needs to be versioned to allow the transitional package to
be installed.

2) Once 'signify-mail' has entered testing, open a ftp.debian.org RM bug
for 'signify' to get the binary packages removed from testing.

This should be done in unstable, not testing.

3) Open a wishlist bug for 'signify-openbsd' with a patch to provide a 'Package: signify' that has /usr/bin/signify and to add:

Conflicts: signify (<= 1.14-7), signify-mail

A package never needs to conflict with an older version of itself. The
conflict with signify-mail is needed only if there is a file name conflict.

Adding the OpenBSD signify under the name "signify" in the trixie cycle
is a bad idea, because existing installations would switch to that.

Instead, signify-mail should provide a transitional binary package
"signify" that pulls in signify-mail. This also overwrites a binary
package from the earlier "signify" source package, and if no other
binaries remain, normal archive cleanup catches that, so no RM is
needed. If other binaries remain, a RM is needed for unstable.

BTS entries can start migrating here as well.

In trixie+1, the transitional binary package is removed (no longer built
from the source package), which, again, does not need an RM.

OpenBSD signify can rename its source package if they want, it does not
matter to users. If they do, BTS entries on the source package should
also be migrated.

In trixie+2, openbsd-signify binary package is renamed to signify (with Depends+Replaces+Conflicts), and a transitional package added to pull it in.

Is a similar Breaks needed too?

Breaks is a Conflicts that does not affect installation ordering
(because there is no actual file conflict, so unpacking in any order is allowed). If Replaces is in place, ordering no longer matters.

The 'signify-openbsd' binary package should be left around as a empty
dummy package for transitions to the new 'signify' binary package.

In trixie+2, yes. It should be removed in trixie+3.

Yes, that's a long timeline.

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FkBVXsI2TPKzXGst2vcgK768
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGkNCg0KT24gMDgtMTAtMjAyNCAwOTowMSwgU2ltb24gSm9zZWZzc29uIHdyb3RlOg0KPiAz KSBPcGVuIGEgd2lzaGxpc3QgYnVnIGZvciAnc2lnbmlmeS1vcGVuYnNkJyB3aXRoIGEgcGF0 Y2ggdG8gcHJvdmlkZSBhDQo+ICdQYWNrYWdlOiBzaWduaWZ5JyB0aGF0IGhhcyAvdXNyL2Jp bi9zaWduaWZ5IGFuZCB0byBhZGQ6DQoNCkRvIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgdGhh dCBzaWduaWZ5LW1haWwgd2lsbCBhbHNvIHByb3ZpZGUgYSANCi91c3IvYmluL3NpZ25pZnk/ IFRoYXQncyBub3QgYWxsb3dlZCBpZiB0aGUgYmluYXJpZXMgaGF2ZSBkaWZmZXJlbnQgDQpm dW5jdGlvbmFsaXR5IFsxXSwgbm90IGV2ZW4gaWYgdGhlIHBhY2thZ2VzIGNvbmZsaWN0LiBT byBhcGFydCBmcm9tIHRoZSANCm5hbWUgb2YgdGhlIHBhY2thZ2VzLCBhbHNvIHRoZSBwYXRo IG5lZWRzIHRvIGFkYXB0ZWQuDQoNClBhdWwNCg0KWzFdIGh0dHBzOi8vd3d3LmRlYmlhbi5v cmcvZG9jL2RlYmlhbi1wb2xpY3kvY2gtZmlsZXMuaHRtbA0KDQo=

--------------FkBVXsI2TPKzXGst2vcgK768--

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmcFjw8FAwAAAAAACgkQnFyZ6wW9dQoC xQf/bMXhxY5ga6PgezVqnEtUmb7PQ47hwbKFEDWj9f4e/9YsCrmmwT5+/ELMKux4C1SCuFeqxfi2 BTY33aOa70+OK06TYe6hO0zfUFdOPaRFMGEOgkob4ZXfPnEwWPqDvsLR42wbgT8oIPqHbRowUC+W pfARYo36QYgKa0a3r8dFxN6xsD+X3YJKeohujX9yzZo8w58uSR/EJXhbfIFMXjp93XMm11q+aanh JjcEl35IDMHSiWddPe5d3+cu4qf6YbJh3l0CpRqY/nwDVPIznd6hdLAbIYEvx8yPc1BLut2ZuNYg zVYyQswyQ4Lh7gxzm2OE/PbNb5vG5x4WVdwOl7UyXA==
=PyBG
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks for review! I tried to revise the plan below, does this work?

I think we should compare this plan to simply remove the 'signify'
package, but haven't fleshed out that plan yet.

/Simon

x) Take current non-OpenBSD 'signify' source package and upload NEW 'signify-mail' package, say version 1.14-8 (?), that provides /usr/bin/signify-mail instead of /usr/bin/signify, and has d/control:

Source: signify-mail
...
Package: signify-mail
Replaces: signify (<= 1.14-7)
Conflicts: signify (<= 1.14-7)
...
Package: signify
Depends: signify-mail
Breaks: signify (<= 1.14-7)
Replaces: signify (<= 1.14-7)
Provides: signify

x) Normal archive cleanup should remove the old 'signify' package. If
this doesn't happen, once 'signify-mail' has entered testing, open a ftp.debian.org RM bug for the old package 'signify' to get the binary
packages removed from unstable.

x) File a wishlist bug for 'signify-openbsd' (with patch) to ALSO
provide /usr/bin/signify (hardlink?), and to add a:

Conflicts: signify (<= 1.14-7)

Could it be a 'Conflicts: signify' to get the transitional dummy package removed after installing 'signify-openbsd'? Or does that just break
upgrades?

x) File a bug to suggest a trixie release note saying that the
non-OpenBSD 'signify' package has been rename to 'signify-mail', and
provides /usr/bin/signify-mail instead. Say that the 'signify-openbsd'
package now provide /usr/bin/signify. Also say that for trixie+1 the
intention is for the OpenBSD signify package to ship a 'signify' package
that provide /usr/bin/signify.

x) Open a bug for 'signify-mail' to say that the transitional package
should be removed in trixie+1.

x) Open a wishlist bug for 'signify-openbsd' (with patch) to track that
in trixie+1 (+2?) it should provide a 'Package: signify' that has /usr/bin/signify and to add:

Conflicts: signify (<= 1.14-7)
Replaces: signify (<= 1.14-7)

The 'signify-openbsd' binary package should be left around as a empty
dummy package for transitions to the new 'signify' binary package:

Package: signify-openbsd
Depends: signify
Breaks: signify-openbsd (<= x.y.z)
Replaces: signify (<= x.y.z)
Provides: signify

Not sure when it makes sense to drop /usr/bin/signify-openbsd from the 'signify' package? trixie+1?

x) OPTIONAL: Open a wishlist bug for 'signify-openbsd' to, after trixie,
upload itself as a NEW 'signify' source package and to ask for removal
of the old 'signify-openbsd' source package. It was suggested this can
trigger BTS bugs, so may not be worth doing. It doesn't really gain
anything except aesthetics.

x) Open a wishlist bug for the OpenBSD signify package to remove the transitional 'signify-openbsd' package for trixie+2 (+3?). The /usr/bin/signify-openbsd name is then also removed.

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZwZGtxQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFojk6AQCXBNAgey+Ate9b5vckERI3cN+IjDcM B4CCNIUjgn6dcAD/axzvCfay+ZIgnZi9lAFu691ysIIB77WQOneRfHn92QY=
=i0gP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul Gevers <elbrus@debian.org> writes:

Hi

On 08-10-2024 09:01, Simon Josefsson wrote:

3) Open a wishlist bug for 'signify-openbsd' with a patch to provide a
'Package: signify' that has /usr/bin/signify and to add:

Do I understand correctly that signify-mail will also provide a /usr/bin/signify?

Yes that was my idea. But maybe that is a bad idea.

That's not allowed if the binaries have different functionality [1],
not even if the packages conflict. So apart from the name of the
packages, also the path needs to adapted.

Good catch. This seems to warrant a trixie release note, to say that
the non-OpenBSD 'signify' package's '/usr/bin/signify' has been renamed
to '/usr/bin/signify-mail', and (hopefully also) that the plan for
trixie+1 is for the OpenBSD 'signify-openbsd' source package to provide
a /usr/bin/signify. That would also make the two packages
co-installable going forward, which is good. This will break people's
scripts, unless they read the release notes and modify their calls to
'signify' into 'signify-mail'.

Interestingly that our processes makes something this simple (renaming a
tool) so complicated to achieve.

Another option is to remove the current non-OpenBSD 'signify' package
that hasn't seen a single update in upstream CVS since 2004. What is
the criteria for keeping a package around when doing so requires a lot
of work from people who have no interest in the particular package, and
nobody who is interested in the particular package steps up to do the
work? Still, the goal of having a OpenBSD /usr/bin/signify is worth
spending time on this for me.

I'll try to provide a revised plan after parsing Simon Richter's e-mail.
Or maybe two plans, one for removal, and one for renaming the package
and tool.

/Simon

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZwY+ARQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFoszkAQD8rXEJSQY+w9ueo3kEbwKpcveHRND2 2uwjCcNh3FLEvAD/ezS/NthfsLmFc6JbSbMb5pFXEUrMg4wkqBhbuxAbQQs=
=tZxk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon Oct 7, 2024 at 8:58 AM BST, Marc Haber wrote:

P.S.: Isnt it about time to rename exim4 to exim?

Or apache2 to apache?

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 10/9/24 18:02, Simon Josefsson wrote:

x) Take current non-OpenBSD 'signify' source package and upload NEW 'signify-mail' package, say version 1.14-8 (?), that provides /usr/bin/signify-mail instead of /usr/bin/signify, and has d/control:

Source: signify-mail
...
Package: signify-mail
Replaces: signify (<= 1.14-7)
Conflicts: signify (<= 1.14-7)

Yes.

Package: signify
Depends: signify-mail

Yes.

Breaks: signify (<= 1.14-7)
Replaces: signify (<= 1.14-7)
Provides: signify

These are unnecessary, because that *is* the "signify" package. It
cannot be installed in parallel with an older version of itself, it
replaces files in an older version of itself, and it satisfies
dependencies on "signify", without any relationships declared.

The short description of the transitional package should begin with "Transitional package" or something like this so it is immediately
obvious in a package list without opening a detail page.

x) Normal archive cleanup should remove the old 'signify' package. If
this doesn't happen, once 'signify-mail' has entered testing, open a ftp.debian.org RM bug for the old package 'signify' to get the binary packages removed from unstable.

Not sure about the timeframe of normal archive cleanup (it is a manual
process triggered by an automated check).

Only the "signify" source package needs to be removed, as the "signify"
binary package is now provided by the "signify-mail" source package,
which leaves the "signify" source package with no binary packages.

x) File a wishlist bug for 'signify-openbsd' (with patch) to ALSO
provide /usr/bin/signify (hardlink?), and to add a:

Conflicts: signify (<= 1.14-7)

Yes.

Could it be a 'Conflicts: signify' to get the transitional dummy package removed after installing 'signify-openbsd'? Or does that just break upgrades?

That just breaks upgrades.

x) File a bug to suggest a trixie release note saying that the
non-OpenBSD 'signify' package has been rename to 'signify-mail', and
provides /usr/bin/signify-mail instead.

Yes. I believe there is also a way to have a notice show up in
apt-listchanges, but I don't exactly remember what triggers that (urgency?).

x) Open a bug for 'signify-mail' to say that the transitional package
should be removed in trixie+1.

Yes.

x) Open a wishlist bug for 'signify-openbsd' (with patch) to track that
in trixie+1 (+2?) it should provide a 'Package: signify' that has /usr/bin/signify and to add:

Ideally, +2, so users will see a release with no "signify" package,
which causes it to be listed under "Obsolete/Local Packages" in aptitude.

Conflicts: signify (<= 1.14-7)

Yes, because there is a file name conflict.

Replaces: signify (<= 1.14-7)

No, because package managers should not treat this as a replacement for
older versions of signify.

The 'signify-openbsd' binary package should be left around as a empty
dummy package for transitions to the new 'signify' binary package:

Package: signify-openbsd
Depends: signify

Yes.

Breaks: signify-openbsd (<= x.y.z)
Replaces: signify (<= x.y.z)
Provides: signify

No. It cannot be co-installed with older versions of itself (so Breaks
does nothing), it does not provide any files that could conflict (so
Replaces does nothing), and it does not provide the same functionality
as the "signify" package (so Provides is wrong).

Not sure when it makes sense to drop /usr/bin/signify-openbsd from the 'signify' package? trixie+1?

It could be left as a symlink in the transitional package, that way
people can easily remove it from their PATH after they have adjusted
their scripts, and it goes away when trixie+3 drops the transitional "signify-openbsd" package.

x) OPTIONAL: Open a wishlist bug for 'signify-openbsd' to, after trixie, upload itself as a NEW 'signify' source package and to ask for removal
of the old 'signify-openbsd' source package. It was suggested this can trigger BTS bugs, so may not be worth doing. It doesn't really gain
anything except aesthetics.

I'd still do that, but in trixie+2, when the package takes over the
"signify" binary package name as well. Moving the old bug reports to "signify-mail" source/binary packages can be done as soon as these exist
in unstable, that also avoids most of the BTS trouble (which is
basically "the BTS does not release-track Maintainer information").

x) Open a wishlist bug for the OpenBSD signify package to remove the transitional 'signify-openbsd' package for trixie+2 (+3?). The /usr/bin/signify-openbsd name is then also removed.

+3. The transitional package is released with +2, and people upgrade to
that version when upgrading between stable releases. This way, they
receive the package with the "Transitional package..." description,
which then shows up in "Obsolete/Local Packages" in +3.

Removing it in +2 would mean that people never receive a package with
this description.

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Oct 09, 2024 at 11:02:47AM +0200, Simon Josefsson wrote:

Thanks for review! I tried to revise the plan below, does this work?

I think we should compare this plan to simply remove the 'signify'
package, but haven't fleshed out that plan yet.

/Simon

x) Take current non-OpenBSD 'signify' source package and upload NEW 'signify-mail' package, say version 1.14-8 (?), that provides /usr/bin/signify-mail instead of /usr/bin/signify, and has d/control:

Source: signify-mail
...
Package: signify-mail
Replaces: signify (<= 1.14-7)
Conflicts: signify (<= 1.14-7)

Hmm. ICBW, but I've always thought that version specifications like
these are best written as (<< fixed-version~) with the added tilde to
also accommodate backports of the fixed version. So in this case,
this would be (<< 1.14-8~), which would:
- catch the 1.14-7 version in the archive (1.14-7)
- catch any 1.14-7+something binNMUs or stable updates
- catch any 1.14-7.x somethign old-style NMUs
- catch any 1.14-7+something local versions that somebody may have
installed on their systems (I sometimes rebuild packages with small
changes and I add a new changelog entry with a +0~0~ringlet.1 suffix
so that any binNMUs or updates will most probably sort later than
the 0~0 part)
- intentionally not catch any 1.14-8~bpoN backports of the new version

Of course, in this particular case the archive only contains 1.14-7,
there are no backports, no stable updates, it seems unlikely that
somebody will upload a NMU in the middle of this discussion, and
the package will most probably not be part of any binNMU campaign,
so in this particular case (<= 1.14-7) would probably work, except for
the low chance of anybody having a 1.14-7+something local version.
Still, I thought I'd mention this for the more general case.

And thanks for holding this discussion in the first place!

G'luck,
Peter

--
Peter Pentchev roam@ringlet.net roam@debian.org peter@morpheusly.com
PGP key: https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmcGn/wACgkQZR7vsCUn 3xPwoQ//T/+I/O6kZj+/lLC/GCcqxnyAeWE0F5ooGAG4KCRA5VUAJ0k87elMRkdw ppsYeMnY2M0uJTCrTX7043hu0G4Tqgy6uQ3FldU8LuvpYwO9V4YQa7mR2co0YuKa bUhmFEEl/Gat6t4MeGdShD9+g+jLN36aJZOqOH40qXQR2DpVbwq9nShRFfRuPIOv Z6Miblhd0MUOnhOK920gpZ/1zxCJG4hi38SBCMASYmuQjBGrgajJex67/IPzZkh8 ikznqUh+4o8FDi412dOIZHoQ86sheVA9PKBPlog6FSzDhR4FtztL3BQjUi3LI6yP g/ruPIF6qeXz+A3mwaR3ONIuC5lkibxnAIIMgVnE8mxalMEmim34C6Fwt9QkpvGh 4ITwKSqa64PXnREAXI8Bo12SHfJaTf+VCFtgPUBT9oIKMSG978cBpLaHfIOWOhPL WnfIU9gzJFJpztjXHpeXZgUa4mGcO2i5tB/nV83ZiDMa3PXZxw9q7i1+S32Xcq2R kZNgZBRA61uL2bCdJwthahVdWIZ9/fCI0TYxzLxRP05oTN8LSU1samck8SJ3/YJU xn7DdF39gYVbyz/zp61JuzIEXfc7Bavwrj5h1yIKRVlRzRkaXesPQdwiZpBk+Vu/ XDrLqCgGeDQGnUFVdEo8RrmksmJaf/tr7qEwFcdvDUfHLlqjvm4=
=9+9V

On Wed, 2024-10-09 at 10:26 +0100, Jonathan Dowland wrote:

On Mon Oct 7, 2024 at 8:58 AM BST, Marc Haber wrote:

P.S.: Isnt it about time to rename exim4 to exim?

Or apache2 to apache?

The ASF is responsible for a lot more than httpd now, and is also
(gradually) moving away from using the Apache name, so if that package
is to be renamed then something like "asf-httpd" would be better.

Ben.

--
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.


-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmcGwJUACgkQ57/I7JWG EQnqEw/6Aj42QLKxOVGNFN8NVurUS9LAowJHk5DF9zpiMU9KHz/iaoVwjpiPqV7r n35Gp1AnIcgdWaJKY/G82Mv+VFVKPi0NpCn2z+VLnlRQtVkDDrVhDTXsRHG45hZX k/dNF+c9my+7IR207QT5nU9DimyM+6DzKVfWaW1OuoQ90wdxjHKGzKvZ4hZx32hU eWjq4MHnbUanA74A07H3PdWmBQjJ8PPkYQVGEw4OV4QJSVFs25TiAZ3uMIBMoXzU GWQFAuj3VXCxEaspsWuwn3LbzyGSsDajgTwtj7NWirCbpugDlWjLlMEQbUOpNVUO WHqBgWbj1Yoxgme4j21xka1M0zoilpi/btT9V52Ztv2KU+H0W4MCclC0vgkMaBBt K6v13nxFVkZSzWd0j9ZGHecpAwxJfWGhQpZdReGFXzgndVxpF92A4g+Kg8Iq9tN2 w2FBK1tK+twHMq5xPxje7un414ldet1ne/yhiBb6L+Q4b3XpsrgvQmaWC5Y8MkPm y1msacgIBYshiWxWa/G7h4KwrvKYzACb5HqypU2dwF4T9sgTTfZpvYk+1f+CVob9 OsW5KBm8vZ2RRhtYcjwjsOJuHvTisu3J3RJRn9C9x6GKvcmjOWrwuEEA8j4xWY8T f7bdHLOxmyTKc+fZRLcHP8IMtJi4GygA0BZNTTtno1K9iKXmKLk=
=414V
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05

Hi!

On Wed, 2024-10-09 at 19:42:45 +0200, Ben Hutchings wrote:

On Wed, 2024-10-09 at 10:26 +0100, Jonathan Dowland wrote:

On Mon Oct 7, 2024 at 8:58 AM BST, Marc Haber wrote:

P.S.: Isnt it about time to rename exim4 to exim?

Or apache2 to apache?

The ASF is responsible for a lot more than httpd now, and is also
(gradually) moving away from using the Apache name, so if that package
is to be renamed then something like "asf-httpd" would be better.

Ah, I was thinking something similar (re httpd) when reading the
original rename proposal, but forgot about the contention on the
"apache" name itself. :)

While I think a rename would be nice, to avoid confusion that would
also imply renaming at least also pathnames (/etc/apache2/,
/usr/lib/apache2/, /usr/share/apache2/, /usr/lib/include/apache2/),
and package names (libapache2-mod-*, *-apache2), which seems like
some work. So better have a good name before embarking on this kind
of change (which I'd applaud TBH).

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On Tue, 2024-10-08 at 09:01:06 +0200, Simon Josefsson wrote:

1) Take current non-OpenBSD 'signify' source package and upload NEW 'signify-mail' with d/control modified as:

Source: signify-mail
...
Package: signify-mail
Replaces: signify (<= 1.14-7)

Do we need 'Breaks: signify (<= 1.14-7)' too? Conflicts?

I've re-read chapter 7 of the policy manual again, but I have read it so
many times before and still don't feel confident about what it actually means. https://www.debian.org/doc/debian-policy/ch-relationships.html

2) Once 'signify-mail' has entered testing, open a ftp.debian.org RM bug
for 'signify' to get the binary packages removed from testing.

3) Open a wishlist bug for 'signify-openbsd' with a patch to provide a 'Package: signify' that has /usr/bin/signify and to add:

Conflicts: signify (<= 1.14-7), signify-mail

Is a similar Breaks needed too?

The 'signify-openbsd' binary package should be left around as a empty
dummy package for transitions to the new 'signify' binary package.

4) Uploading source package 'signify-openbsd' to NEW as 'signify', and
then ask for removal of the old 'signify-openbsd' source package. This
is nice but optional. It was suggested this can trigger BTS bugs. It
may be best to wait until at least trixie+1. This doesn't affect users
so is more of an developer aesthetic concern, which may suggest it isn't worth doing at all.

Not digging into the packaging side of things, but I think you can
probably optimize/reduce NEW trips and archive admins intervention, by
taking into account that (AFAIR and if things have not changed?) source
package renames do not go through NEW. That you can take over (also
AFAIR if things have not changed) a binary package from another source
package. And that binaries no longer produced by any source get
automatically garbage collected (https://wiki.debian.org/Glossary#nbs).

So depending on the timelines, the process could be reduced by staging
the binary package moves/take-overs and source package renames in
different ordered uploads.

Thanks,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On October 15, 2024 12:20:27 PM UTC, Guillem Jover <guillem@debian.org> wrote: >Hi!

On Tue, 2024-10-08 at 09:01:06 +0200, Simon Josefsson wrote:

1) Take current non-OpenBSD 'signify' source package and upload NEW
'signify-mail' with d/control modified as:

Source: signify-mail
...
Package: signify-mail
Replaces: signify (<= 1.14-7)

Do we need 'Breaks: signify (<= 1.14-7)' too? Conflicts?

I've re-read chapter 7 of the policy manual again, but I have read it so
many times before and still don't feel confident about what it actually
means. https://www.debian.org/doc/debian-policy/ch-relationships.html

2) Once 'signify-mail' has entered testing, open a ftp.debian.org RM bug
for 'signify' to get the binary packages removed from testing.

3) Open a wishlist bug for 'signify-openbsd' with a patch to provide a
'Package: signify' that has /usr/bin/signify and to add:

Conflicts: signify (<= 1.14-7), signify-mail

Is a similar Breaks needed too?

The 'signify-openbsd' binary package should be left around as a empty
dummy package for transitions to the new 'signify' binary package.

4) Uploading source package 'signify-openbsd' to NEW as 'signify', and
then ask for removal of the old 'signify-openbsd' source package. This
is nice but optional. It was suggested this can trigger BTS bugs. It
may be best to wait until at least trixie+1. This doesn't affect users
so is more of an developer aesthetic concern, which may suggest it isn't
worth doing at all.

Not digging into the packaging side of things, but I think you can
probably optimize/reduce NEW trips and archive admins intervention, by
taking into account that (AFAIR and if things have not changed?) source >package renames do not go through NEW. That you can take over (also
AFAIR if things have not changed) a binary package from another source >package. And that binaries no longer produced by any source get
automatically garbage collected (https://wiki.debian.org/Glossary#nbs).

So depending on the timelines, the process could be reduced by staging
the binary package moves/take-overs and source package renames in
different ordered uploads.

They do go through New.

Scott K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)