Bug#1031376: tzdata 2022g-3 removed /etc/timezone without a proper transition, breaking multiple packages
On Thu, 2023-02-16 at 13:59 +0100, Michael Biebl wrote:
> [Looping Benjamin in]
>
> Hi everyone,
>
> the removal of /etc/timezone was discussed in the context of a systemd
> upload targeting experimental, where I suggested this should be handled
> by the tzdata package and not by systemd, as I considered tzdata the
> "primary" owner of that file [1]. systemd-localed also handles that file
> currently via a Debian specific patch, which we'd like to get rid of.
> The information in /etc/timezone is basically redundant as you can just
> as easily get the information from looking where the /etc/localtime
> symlink points at. It also avoids that /etc/localtime and /etc/timezone
> get out-of-sync.
> /etc/timezone is mostly a Debianism afaiu.
>
> Benjamin was so kind to implement this suggestion swiftly and uploaded
> this to unstable.
> If this is now causing regressions in several packages, it's probably ok
> to revert this change for bookworm.
> I did briefly skim over the codesearch list, and found a lot of false
> positives and fixes for this issue are usually pretty simple, but yes,
> I'd say this could be done early in the trixie release cycle as well
> with an accompanying MBF.
>
> Benjamin, would it cause a lot of trouble to revert this change again or
> how would you prefer to proceed?
I agree that restoring /etc/timezone is the right solution for the
bookworm. I'll prepare a tzdata upload for it.
> [1] https://salsa.debian.org/systemd-team/systemd/-/merge_requests/189
>
> Am 16.02.23 um 13:30 schrieb Sebastian Ramacher:
> > On 2023-02-16 12:34:29 +0100, Daniel Leidert wrote:
> > > Am Donnerstag, dem 16.02.2023 um 08:41 +0100 schrieb Paul Gevers:
> > > > Control: tags -1 moreinfo
> > > > Control: severity -1 normal
> > > >
> > > > Hi Daniel,
> > > >
> > > > On 16-02-2023 01:11, Daniel Leidert wrote:
> > > > > I ask you to
> > > > > find a reasonable approach to deal with this for the Bookworm
> > > > > release.
> > > >
> > > > That's not how we normally work. Please come with concrete proposals and
> > > > we can evaluate them.
> > >
> > > Hi Paul. That is the release team's job. Your team should be on top of
> > > that situation and control that. There is already a freeze in process.
> > > You made that very clear. New transitions are not allowed. The date has
> > > passed that re-introductions into Testing are not allowed anymore. And
> > > people break other packages just like that? It is my expectation that
> > > your team evaluates the situation together with the maintainer of
> > > tzdata now, and then comes to a conclusion and a decision, how this
> > > should be handled. codesearch.d.o proves that multiple packages use
> > > code that relies on the existence of /etc/timezone. So, its removal
> > > should have been handled in a coordinated way in the first place.
> > > Either the maintainer of tzdata does a mass-bug filing, or this change
> > > should be reverted.
> >
> > I suggest you file a bug with the package that introduced any
> > breakage first. I see no such bug against tzdata.
> >
> > Cheers
> >
> > >
> > > I have already spent two dozen unpaid hours of tracking down and
> > > handling breakages introduced since February 7th(!!) by fellow DDs. I
> > > spent multiple dozen hours of bug-fixing and uploading since the new
> > > year started, to make sure users will get the software they expect in
> > > Bookworm, also unpaid of course. And now I have to evaluate the impact
> > > of the change in tzdata as well and create proposals? No. I'm not the
> > > tzdata maintainer and I'm not a member of the release team. It is your
> > > job to handle transitions.
> > >
> > > <frustrated>
> > > And I suggest that you finally do your job and make sure that people
> > > stop uploading breaking changes, so the work for Bookworm gets less and
> > > not constantly more.
> > > </frustrated>
> > >
> > > Daniel
> > >
> >
>
--
Benjamin Drung
Debian & Ubuntu Developer
Reply to: