Re: epoch bump request for gnome-calculator
Hi Jeremy,
My comments below for what it's worth. You should likely not
take anything I say too seriously, but maybe I happen to mention
something that can be food for thought.
On Wed, Sep 26, 2018 at 09:47:38AM -0400, Jeremy Bicha wrote:
> Emailing both debian-devel and the Debian GNOME mailing list.
>
> I am requesting project approval for me to upload gnome-calculator
> with an epoch.
>
> Five years ago, gcalctool 6.4 was renamed to gnome-calculator and
> renumbered to 3.8. This seemed like a clear case for an epoch since
> this was a permanent change in the version numbering scheme.
For me, wherever a (source and binary) package is removed it's
a clear case that it's an opportunity to *get rid* of epochs.
Upstream renaming things are a rare opportunity and should
be utilized!
>
> I made this change in the Debian VCS and uploaded it to Ubuntu. At the
> time I did not have upload rights to Debian and Ubuntu has deadlines.
>
> A month later, a Debian GNOME team member recognized that we could use
> a dh_gencontrol hack [1] to only add the epoch to the gcalctool
> transitional package and we didn't need an epoch for gnome-calculator.
> Similarly, we could have used this hack for many of the gnome-games
> packages when they were split into separate source packages but we
> didn't because we uploaded them before we made this change. (The
> version numbering didn't change but gnome-games had an epoch we didn't
> need to carry to the new packages.)
I feel like I was probably the guilty person here. Possibly having
higher-than-average dislike for epochs and also being clueless
on ubuntu deadlines. I feel like rushing an epoch bump in because
of a deadline is a bad idea, which you are probably well aware of
as of now.
(And yes, there where probably more cases this should have been
used but once uploaded the window of opportunity to eliminate the
epochs are gone and we have to wait, pray and hope that upstream
renames things again some time in the future.)
Also Debhelper commands are overridable by design and their individual
arguments are documented in their separate manual pages. This should
be leveraged when ever it's the appropriate thing to do (and avoided
when it's not).
>
> More recently, I have worked to reduce the difference between Debian
> and Ubuntu packaging for many GNOME packages. It gets very tedious to
> need to upload gnome-calculator in Debian and then do a separate
> upload in Ubuntu (along with all the required Vcs merging, updating
> and tagging) just to add the epoch in Ubuntu. It would be a lot nicer
> if I could just sync the Debian package to Ubuntu.
>
> So is it appropriate to bump an epoch in Debian to match an important
> downstream's epoch?
I understand this is annoying for you to have to carry forever in
ubuntu, so I'm willing to look the other way with one condition:
You make sure to discuss policies on the ubuntu side to take
extra care to not needlessly introduce epoch bumps which you then
later come to debian to discuss because it's causing you pain in
ubuntu. If you ever bump epoch in ubuntu without having done
the full epoch-dance in debian and waited for it to actually be
uploaded to the debian archive before you upload the epoch bump
in ubuntu, then you agree to handle it for all eternity on the
ubuntu side when needed.
As an alternative suggestion, why isn't it possible to simply
get rid of the annoying part by specifying a vendor-condition
in debian/rules and apply "the hack" to all binary packages
when building on ubuntu (and on transitional packages only
when building on debian)?
Carrying this ubuntu-specific lines in debian/rules even in
debian would likely be something that people who only care
for debian could more easily accept.
eg.
ifeq ($(DEB_VENDOR),Ubuntu)
<insert "the hack" here>
endif
>
> [1] Current example of the hack:
> https://salsa.debian.org/fonts-team/fonts-ubuntu/blob/debian/unstable/debian/rules
>
> Thanks,
> Jeremy Bicha
>
Regards,
Andreas Henriksson
(who hasn't mastered the art of writing short mails yet either)
Reply to: