re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
(non-subscriber, please keep me in CC) Someone filed a bug asking to re-introduce an epoch. An older fork of the same package back in Wheezy last featured the epoch. Personally, I'm fine with either marking the bug as WONTFIX or re-introducing the epoch for one specific binary target whose name matches what was last seen in Wheezy. I simply want to hear what is the mailing list's concensus. Martin-Éric
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
Hi Martin-Éric, Martin-Éric Racine, on 2023-06-16: > (non-subscriber, please keep me in CC) Acknowledged. > Someone filed a bug asking to re-introduce an epoch. > > An older fork of the same package back in Wheezy last featured the epoch. > > Personally, I'm fine with either marking the bug as WONTFIX or > re-introducing the epoch for one specific binary target whose name > matches what was last seen in Wheezy. I simply want to hear what is > the mailing list's concensus. Hmn, hard to tell, I tend to believe the severity is justified, as one could have carried the old dhcpcd package over a number of Debian versions since wheezy, and won't get the dhcpcd you introduced. On the other hand, you mention your package is a different implementation, so perhaps the version bump from the old fork to your package might have unintended effects, for instance if configuration file formats and such were to have evolved. The bug seems to only affect your binary package dhcpcd, so maybe a possible option could be to move ressources provided by the dhcpcd package to dhcpcd5 and remove the dhcpcd package. It would avoid you the epoch bump and the hassle to handle the version bump from the old fork, but it also might confuse people using the package. What do you think? Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On Sat, Jun 17, 2023 at 12:40 PM Étienne Mollier wrote: > Martin-Éric Racine, on 2023-06-16: > > Someone filed a bug asking to re-introduce an epoch. > > > > An older fork of the same package back in Wheezy last featured the epoch. > > > > Personally, I'm fine with either marking the bug as WONTFIX or > > re-introducing the epoch for one specific binary target whose name > > matches what was last seen in Wheezy. I simply want to hear what is > > the mailing list's concensus. > > The bug seems to only affect your binary package dhcpcd, so > maybe a possible option could be to move ressources provided by > the dhcpcd package to dhcpcd5 and remove the dhcpcd package. It > would avoid you the epoch bump and the hassle to handle the > version bump from the old fork, but it also might confuse people > using the package. What do you think? If you look at the other open bug, the point precisely was to get rid of the 5 completely. I found a simple override that would re-introduce the epoch only for bin:dhcpcd (but not for bin:dhcpcd-base or the transitional bin:dhcpcd5). I however wonder whether this is worth the trouble, given how far back the last occurrence of bin:dhcpcd goes. This being said, archive policy might mandate doing this even if the last occurrence of bin:dhcpcd dates back from 2016. Martin-Éric
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
Hi! On Sat, 2023-06-17 at 11:39:51 +0200, Étienne Mollier wrote: > Martin-Éric Racine, on 2023-06-16: > > Someone filed a bug asking to re-introduce an epoch. > > > > An older fork of the same package back in Wheezy last featured the epoch. > > > > Personally, I'm fine with either marking the bug as WONTFIX or > > re-introducing the epoch for one specific binary target whose name > > matches what was last seen in Wheezy. I simply want to hear what is > > the mailing list's concensus. > > Hmn, hard to tell, I tend to believe the severity is justified, > as one could have carried the old dhcpcd package over a number > of Debian versions since wheezy, and won't get the dhcpcd you > introduced. While I guess in general and in theory this would apply, in this particular case I think the following does make some sense: > On the other hand, you mention your package is a > different implementation, so perhaps the version bump from the > old fork to your package might have unintended effects, for > instance if configuration file formats and such were to have > evolved. By reading #594672 and a quick skim over #551034, these seem to have been the same project, but the version introduced later as dhcpcd5 was a new major version with an incompatible redesign, which would break on upgrade, that's why it was not packaged at the time using the same source package. So to me it makes sense to avoid adding the epoch to avoid automatic upgrades like it was avoided in the past, otherwise people might expect a smooth upgrade path. Also for reference the old dhcpcd was removed from Debian in 2014: https://packages.qa.debian.org/d/dhcpcd.html Unfortunately, even though this was long ago, there seems to still be a short tail of such package installed on systems: https://qa.debian.org/popcon.php?package=dhcpcd5 > The bug seems to only affect your binary package dhcpcd, so > maybe a possible option could be to move ressources provided by > the dhcpcd package to dhcpcd5 and remove the dhcpcd package. It > would avoid you the epoch bump and the hassle to handle the > version bump from the old fork, but it also might confuse people > using the package. What do you think? The only problem I see with leaving things as is, is that some users might not notice they need to upgrade. It would be nice if we had some way to notify of these kind of obsolete packages or upgrades. But if you end up deciding on adding the epoch, then yeah please, just add it to the affected binary package (even though in this case that matches the source package, so it's going to be sticking forever I guess anyway :/). Thanks, Guillem
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On Sat, Jun 17, 2023 at 6:39 PM Guillem Jover wrote: > By reading #594672 and a quick skim over #551034, these seem to have > been the same project, but the version introduced later as dhcpcd5 was > a new major version with an incompatible redesign, which would break > on upgrade, that's why it was not packaged at the time using the same > source package. So to me it makes sense to avoid adding the epoch to > avoid automatic upgrades like it was avoided in the past, otherwise > people might expect a smooth upgrade path. Also for reference the old > dhcpcd was removed from Debian in 2014: > > https://packages.qa.debian.org/d/dhcpcd.html 2016. > Unfortunately, even though this was long ago, there seems to still be > a short tail of such package installed on systems: > > https://qa.debian.org/popcon.php?package=dhcpcd5 Most of these are likely the result of transitional dhcpcd5 pulling in dhcpcd. > > The bug seems to only affect your binary package dhcpcd, so > > maybe a possible option could be to move ressources provided by > > the dhcpcd package to dhcpcd5 and remove the dhcpcd package. It > > would avoid you the epoch bump and the hassle to handle the > > version bump from the old fork, but it also might confuse people > > using the package. What do you think? > > The only problem I see with leaving things as is, is that some users > might not notice they need to upgrade. It would be nice if we had some > way to notify of these kind of obsolete packages or upgrades. > > But if you end up deciding on adding the epoch, then yeah please, just > add it to the affected binary package (even though in this case that > matches the source package, so it's going to be sticking forever I guess > anyway :/). # Wheezy had (1:3.2.3-11+deb7u1) so reintroduce the epoch for one target. override_dh_gencontrol: dh_gencontrol --package=dhcpcd -- -v1:$(DEB_VERSION_UPSTREAM_REVISION) dh_gencontrol --remaining-packages This is what I would do if the archive policy demands it. Won't affect transitional dhcpcd5 or dhcpcd-base. Martin-Éric
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On 17/06/2023 20.30, Martin-Éric Racine wrote:
This is what I would do if the archive policy demands it. Won't affect
transitional dhcpcd5 or dhcpcd-base.
Ack.
I'm not sure whether the transitional dhcpcd5 package should have a
versioned dependency on the "right" dhcpcd, either
(= 1:${binary:Version}) or (>= 1:9). IIRC you need to add the epoch
manually in the former case.
Andreas
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On Sat, Jun 17, 2023 at 11:44 PM Andreas Beckmann wrote:
>
> On 17/06/2023 20.30, Martin-Éric Racine wrote:
> > This is what I would do if the archive policy demands it. Won't affect
> > transitional dhcpcd5 or dhcpcd-base.
>
> Ack.
>
> I'm not sure whether the transitional dhcpcd5 package should have a
> versioned dependency on the "right" dhcpcd, either
> (= 1:${binary:Version}) or (>= 1:9). IIRC you need to add the epoch
> manually in the former case.
Merely re-introducing the epoch for bin:dhcpcd ought to be enough.
dhcpcd5 depends on a versionless dhcpcd. Thus:
override_dh_gencontrol:
dh_gencontrol --package=dhcpcd -- -v1:$(DEB_VERSION_UPSTREAM_REVISION)
dh_gencontrol --remaining-packages
Would probably be enough to make this policy-compliant again.
Martin-Éric
