Bug#822733: tzdata: Drop /etc/timezone

[Benjamin Drung]

On Wed, 2023-02-08 at 12:08 +0100, Aurelien Jarno wrote:
> Hi,
> 
> On 2023-02-07 23:39, Michael Biebl wrote:
> > Hi
> > 
> > Am 07.02.23 um 23:01 schrieb Aurelien Jarno:
> > 
> > > 2022g-3. You probably want to change d-i to not create that file.
> > 
> > Where specifically does d-i (i.e. which component)  create /etc/timezone?
> 
> This is done in tzsetup.

Here you go:
https://salsa.debian.org/installer-team/tzsetup/-/merge_requests/3

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#822733: tzdata: Drop /etc/timezone

[Aurelien Jarno]

Hi,

On 2023-02-07 23:39, Michael Biebl wrote:
> Hi
> 
> Am 07.02.23 um 23:01 schrieb Aurelien Jarno:
> 
> > 2022g-3. You probably want to change d-i to not create that file.
> 
> Where specifically does d-i (i.e. which component)  create /etc/timezone?

This is done in tzsetup.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#822733: tzdata: Drop /etc/timezone

[Michael Biebl]

Hi

Am 07.02.23 um 23:01 schrieb Aurelien Jarno:


2022g-3. You probably want to change d-i to not create that file.


Where specifically does d-i (i.e. which component)  create /etc/timezone?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#822733: tzdata: Drop /etc/timezone

[Aurelien Jarno]

On 2023-02-06 13:05, Benjamin Drung wrote:
> On Sun, 2023-01-29 at 15:45 +0100, Michael Biebl wrote:
> > Am 29.01.2023 um 15:38 schrieb Luca Boccassi:
> > > On Sun, 29 Jan 2023, 13:15 Michael Biebl,  > > > wrote:
> > > 
> > > Am 28.01.2023 um 02:12 schrieb Luca Boccassi:
> > >  > I'm looking at this again, because handling /etc/timezone is one
> > > of the
> > >  > last large technical debt patches that we carry in Debian for
> > >  > src:systemd, and we want to drop it for Trixie.
> > >  > The idea is to add a tmpfiles.d entry in the systemd package that
> > >  > unconditionally deletes /etc/timezone if present. If someone wants 
> > > to
> > >  > keep using it, they can simply override the tmpfiles.d entry with 
> > > the
> > >  > usual mechanisms.
> > >  >
> > >  > So, could you please reconsider the proposal to stop creating it
> > > if it
> > >  > doesn't exist (but keep updating if it does) in the tzdata
> > > postinst as
> > >  > above for Trixie?
> > > 
> > > I'm a bit confused: If you forcefully want to delete /etc/timezone
> > > via a
> > > tmpfiles snippet, why let tzdata update an existing /etc/timezone?
> > > 
> > > 
> > > Because it can be overridden as mentioned, so in case there are unknown 
> > > corner cases where it's still needed, a drop-in can be added to avoid 
> > > deleting the file and it will still get updated. In the future we can 
> > > then consider removing this as well.
> > > 
> > 
> > I would prefer, if all this is handled within tzdata.
> > - It should stop creating /etc/timezone
> > - It should delete /etc/timezone on upgrades as a one-time action

Note that this means that newly installed systems will still have
/etc/timezone, as they won't see the upgrade from versions older than
2022g-3. You probably want to change d-i to not create that file.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#822733: tzdata: Drop /etc/timezone

[Luca Boccassi]

On Mon, 6 Feb 2023 at 13:13, Benjamin Drung  wrote:
>
> On Sun, 2023-01-29 at 15:45 +0100, Michael Biebl wrote:
> > Am 29.01.2023 um 15:38 schrieb Luca Boccassi:
> > > On Sun, 29 Jan 2023, 13:15 Michael Biebl,  > > > wrote:
> > >
> > > Am 28.01.2023 um 02:12 schrieb Luca Boccassi:
> > >  > I'm looking at this again, because handling /etc/timezone is one
> > > of the
> > >  > last large technical debt patches that we carry in Debian for
> > >  > src:systemd, and we want to drop it for Trixie.
> > >  > The idea is to add a tmpfiles.d entry in the systemd package that
> > >  > unconditionally deletes /etc/timezone if present. If someone wants 
> > > to
> > >  > keep using it, they can simply override the tmpfiles.d entry with 
> > > the
> > >  > usual mechanisms.
> > >  >
> > >  > So, could you please reconsider the proposal to stop creating it
> > > if it
> > >  > doesn't exist (but keep updating if it does) in the tzdata
> > > postinst as
> > >  > above for Trixie?
> > >
> > > I'm a bit confused: If you forcefully want to delete /etc/timezone
> > > via a
> > > tmpfiles snippet, why let tzdata update an existing /etc/timezone?
> > >
> > >
> > > Because it can be overridden as mentioned, so in case there are unknown
> > > corner cases where it's still needed, a drop-in can be added to avoid
> > > deleting the file and it will still get updated. In the future we can
> > > then consider removing this as well.
> > >
> >
> > I would prefer, if all this is handled within tzdata.
> > - It should stop creating /etc/timezone
> > - It should delete /etc/timezone on upgrades as a one-time action
> > - If users manually create the file afterwards (say touch /etc/timezone)
> > a dpkg-reconfigure tzdata would update the file.
>
> I will implement exactly this for tzdata since that approach makes the
> most sense.

Sounds great, thank you

Bug#822733: tzdata: Drop /etc/timezone

[Benjamin Drung]

On Sun, 2023-01-29 at 15:45 +0100, Michael Biebl wrote:
> Am 29.01.2023 um 15:38 schrieb Luca Boccassi:
> > On Sun, 29 Jan 2023, 13:15 Michael Biebl,  > > wrote:
> > 
> > Am 28.01.2023 um 02:12 schrieb Luca Boccassi:
> >  > I'm looking at this again, because handling /etc/timezone is one
> > of the
> >  > last large technical debt patches that we carry in Debian for
> >  > src:systemd, and we want to drop it for Trixie.
> >  > The idea is to add a tmpfiles.d entry in the systemd package that
> >  > unconditionally deletes /etc/timezone if present. If someone wants to
> >  > keep using it, they can simply override the tmpfiles.d entry with the
> >  > usual mechanisms.
> >  >
> >  > So, could you please reconsider the proposal to stop creating it
> > if it
> >  > doesn't exist (but keep updating if it does) in the tzdata
> > postinst as
> >  > above for Trixie?
> > 
> > I'm a bit confused: If you forcefully want to delete /etc/timezone
> > via a
> > tmpfiles snippet, why let tzdata update an existing /etc/timezone?
> > 
> > 
> > Because it can be overridden as mentioned, so in case there are unknown 
> > corner cases where it's still needed, a drop-in can be added to avoid 
> > deleting the file and it will still get updated. In the future we can 
> > then consider removing this as well.
> > 
> 
> I would prefer, if all this is handled within tzdata.
> - It should stop creating /etc/timezone
> - It should delete /etc/timezone on upgrades as a one-time action
> - If users manually create the file afterwards (say touch /etc/timezone) 
> a dpkg-reconfigure tzdata would update the file.

I will implement exactly this for tzdata since that approach makes the
most sense.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#822733: tzdata: Drop /etc/timezone

[Luca Boccassi]

On Sun, 29 Jan 2023 at 14:45, Michael Biebl  wrote:
>
> Am 29.01.2023 um 15:38 schrieb Luca Boccassi:
> > On Sun, 29 Jan 2023, 13:15 Michael Biebl,  > > wrote:
> >
> > Am 28.01.2023 um 02:12 schrieb Luca Boccassi:
> >  > I'm looking at this again, because handling /etc/timezone is one
> > of the
> >  > last large technical debt patches that we carry in Debian for
> >  > src:systemd, and we want to drop it for Trixie.
> >  > The idea is to add a tmpfiles.d entry in the systemd package that
> >  > unconditionally deletes /etc/timezone if present. If someone wants to
> >  > keep using it, they can simply override the tmpfiles.d entry with the
> >  > usual mechanisms.
> >  >
> >  > So, could you please reconsider the proposal to stop creating it
> > if it
> >  > doesn't exist (but keep updating if it does) in the tzdata
> > postinst as
> >  > above for Trixie?
> >
> > I'm a bit confused: If you forcefully want to delete /etc/timezone
> > via a
> > tmpfiles snippet, why let tzdata update an existing /etc/timezone?
> >
> >
> > Because it can be overridden as mentioned, so in case there are unknown
> > corner cases where it's still needed, a drop-in can be added to avoid
> > deleting the file and it will still get updated. In the future we can
> > then consider removing this as well.
> >
>
> I would prefer, if all this is handled within tzdata.
> - It should stop creating /etc/timezone
> - It should delete /etc/timezone on upgrades as a one-time action
> - If users manually create the file afterwards (say touch /etc/timezone)
> a dpkg-reconfigure tzdata would update the file.
>
> This should all be under tzdata's control.

Without the tmpfiles.d in src:systemd, we can't drop the patch for one
release I'd think?

Bug#822733: tzdata: Drop /etc/timezone

[Michael Biebl]

Am 29.01.2023 um 15:38 schrieb Luca Boccassi:
On Sun, 29 Jan 2023, 13:15 Michael Biebl, > wrote:


Am 28.01.2023 um 02:12 schrieb Luca Boccassi:
 > I'm looking at this again, because handling /etc/timezone is one
of the
 > last large technical debt patches that we carry in Debian for
 > src:systemd, and we want to drop it for Trixie.
 > The idea is to add a tmpfiles.d entry in the systemd package that
 > unconditionally deletes /etc/timezone if present. If someone wants to
 > keep using it, they can simply override the tmpfiles.d entry with the
 > usual mechanisms.
 >
 > So, could you please reconsider the proposal to stop creating it
if it
 > doesn't exist (but keep updating if it does) in the tzdata
postinst as
 > above for Trixie?

I'm a bit confused: If you forcefully want to delete /etc/timezone
via a
tmpfiles snippet, why let tzdata update an existing /etc/timezone?


Because it can be overridden as mentioned, so in case there are unknown 
corner cases where it's still needed, a drop-in can be added to avoid 
deleting the file and it will still get updated. In the future we can 
then consider removing this as well.




I would prefer, if all this is handled within tzdata.
- It should stop creating /etc/timezone
- It should delete /etc/timezone on upgrades as a one-time action
- If users manually create the file afterwards (say touch /etc/timezone) 
a dpkg-reconfigure tzdata would update the file.


This should all be under tzdata's control.

Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#822733: tzdata: Drop /etc/timezone

[Luca Boccassi]

On Sun, 29 Jan 2023, 13:15 Michael Biebl,  wrote:

> Am 28.01.2023 um 02:12 schrieb Luca Boccassi:
> > I'm looking at this again, because handling /etc/timezone is one of the
> > last large technical debt patches that we carry in Debian for
> > src:systemd, and we want to drop it for Trixie.
> > The idea is to add a tmpfiles.d entry in the systemd package that
> > unconditionally deletes /etc/timezone if present. If someone wants to
> > keep using it, they can simply override the tmpfiles.d entry with the
> > usual mechanisms.
> >
> > So, could you please reconsider the proposal to stop creating it if it
> > doesn't exist (but keep updating if it does) in the tzdata postinst as
> > above for Trixie?
>
> I'm a bit confused: If you forcefully want to delete /etc/timezone via a
> tmpfiles snippet, why let tzdata update an existing /etc/timezone?
>

Because it can be overridden as mentioned, so in case there are unknown
corner cases where it's still needed, a drop-in can be added to avoid
deleting the file and it will still get updated. In the future we can then
consider removing this as well.

>

Bug#822733: tzdata: Drop /etc/timezone

[Michael Biebl]

Am 28.01.2023 um 02:12 schrieb Luca Boccassi:

I'm looking at this again, because handling /etc/timezone is one of the
last large technical debt patches that we carry in Debian for
src:systemd, and we want to drop it for Trixie.
The idea is to add a tmpfiles.d entry in the systemd package that
unconditionally deletes /etc/timezone if present. If someone wants to
keep using it, they can simply override the tmpfiles.d entry with the
usual mechanisms.

So, could you please reconsider the proposal to stop creating it if it
doesn't exist (but keep updating if it does) in the tzdata postinst as
above for Trixie?


I'm a bit confused: If you forcefully want to delete /etc/timezone via a 
tmpfiles snippet, why let tzdata update an existing /etc/timezone?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#822733: tzdata: Drop /etc/timezone

[Luca Boccassi]

On Wed, 27 Apr 2016 11:41:14 +0200 Martin Pitt 
wrote:
> Hello Aurelien,
> 
> Aurelien Jarno [2016-04-27 11:13 +0200]:
> > Unfortunately it seems a lot of software are actually using
> > /etc/timezone to configure the time zone. When switching to a
symlink
> > this made people unhappy, see for example bug#813226. This bug
points to
> > the following query:
> > 
> >
https://github.com/search?q=%2Fetc%2Ftimezone+dpkg-reconfigure+noninteractive+tzdata=Code=%E2%9C%93
> 
> Interesting, thanks for that link. It seems the majority is writing
> that file for a subsequent dpkg-reconfigure, but I've seen a few
reads
> as well. It seems over time a lot of software out there has adopted
> this Debianism.
> 
> Wrt. to #813226, I admittedly don't understand why /etc/localtime
> being a file or symlink is in any way related to which of
> /etc/localtime vs. /etc/timezone should have priority over the other
> on reconfiguration. I mean, the *.config scripts surely may treat
them
> differently, but that's just an implementation detail, not a
> conceptual/design problem?
> 
> Software (both tzdata itself and also other things reading/changing
> it) needs to get along with /etc/localtime being a symlink either
way,
> even before tzdata 2016a-1.
> 
> > What we can probably do is to stop looking or creating
/etc/timezone
> > if it doesn't exist, but keep updating it if it exists. What do you
> > think?
> 
> That might be cleaner in situations where someone explicitly removes
> it, but a lot less useful to avoid the redundancy problem.
> 
> Anyway, it seems to me that this is too deeply entrenched in the
> software world by now, so  I figure is is a case for 'wontfix' and
> just closing this report?
> 
> Thanks!
> 
> Martin

Hi,

I'm looking at this again, because handling /etc/timezone is one of the
last large technical debt patches that we carry in Debian for
src:systemd, and we want to drop it for Trixie.
The idea is to add a tmpfiles.d entry in the systemd package that
unconditionally deletes /etc/timezone if present. If someone wants to
keep using it, they can simply override the tmpfiles.d entry with the
usual mechanisms.

So, could you please reconsider the proposal to stop creating it if it
doesn't exist (but keep updating if it does) in the tzdata postinst as
above for Trixie?

Thanks!

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#822733: tzdata: Drop /etc/timezone

[Martin Pitt]

Hello Aurelien,

Aurelien Jarno [2016-04-27 11:13 +0200]:
> Unfortunately it seems a lot of software are actually using
> /etc/timezone to configure the time zone. When switching to a symlink
> this made people unhappy, see for example bug#813226. This bug points to
> the following query:
> 
> https://github.com/search?q=%2Fetc%2Ftimezone+dpkg-reconfigure+noninteractive+tzdata=Code=%E2%9C%93

Interesting, thanks for that link. It seems the majority is writing
that file for a subsequent dpkg-reconfigure, but I've seen a few reads
as well. It seems over time a lot of software out there has adopted
this Debianism.

Wrt. to #813226, I admittedly don't understand why /etc/localtime
being a file or symlink is in any way related to which of
/etc/localtime vs. /etc/timezone should have priority over the other
on reconfiguration. I mean, the *.config scripts surely may treat them
differently, but that's just an implementation detail, not a
conceptual/design problem?

Software (both tzdata itself and also other things reading/changing
it) needs to get along with /etc/localtime being a symlink either way,
even before tzdata 2016a-1.

> What we can probably do is to stop looking or creating /etc/timezone
> if it doesn't exist, but keep updating it if it exists. What do you
> think?

That might be cleaner in situations where someone explicitly removes
it, but a lot less useful to avoid the redundancy problem.

Anyway, it seems to me that this is too deeply entrenched in the
software world by now, so  I figure is is a case for 'wontfix' and
just closing this report?

Thanks!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#822733: tzdata: Drop /etc/timezone

[Aurelien Jarno]

On 2016-04-26 23:37, Martin Pitt wrote:
> Package: tzdata
> Version: 2016d-2
> Severity: wishlist
> 
> /etc/localtime got turned into a symlink in 2016a-1 (see bug #803144),
> now that /usr gets mounted from the initrd.
> 
> This now leaves /etc/timezone completely redundant, as you should get
> exactly the same answer by readlink /etc/localtime -- and if you do
> not get the same answer, you have an inconsistency. /etc/localtime
> obviously "wins" for the actual clock (as that's what programs are
> reading), but you presumably get the /etc/timezone value in some
> "system configuration tool" packages which read /etc/timezone first.
> 
> https://codesearch.debian.net/perpackage-results/%2Fetc%2Ftimezone
> shows a fair number of hits, but it's actually not so bad: as
> /etc/timezone is a Debianism and /etc/localtime the distro-agnostic
> standard, a lot of software which isn't Debian specific already looks
> at both and only falls back to /etc/timezone if /etc/localtime does
> not exist. A desktop installation boots fine and with the correct
> time/zone after removing /etc/timezone.

Unfortunately it seems a lot of software are actually using
/etc/timezone to configure the time zone. When switching to a symlink
this made people unhappy, see for example bug#813226. This bug points to
the following query:

https://github.com/search?q=%2Fetc%2Ftimezone+dpkg-reconfigure+noninteractive+tzdata=Code=%E2%9C%93

> If you are generally open to the idea, I can look through the above
> codesearch results more closely to see which packages need fixing,
> file bugs, and block this bug on those. But as that's quite some work,
> I'd first like to discuss this with you.

What we can probably do is to stop looking or creating /etc/timezone
if it doesn't exist, but keep updating it if it exists. What do you
think?

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#822733: tzdata: Drop /etc/timezone

[Martin Pitt]

Package: tzdata
Version: 2016d-2
Severity: wishlist

/etc/localtime got turned into a symlink in 2016a-1 (see bug #803144),
now that /usr gets mounted from the initrd.

This now leaves /etc/timezone completely redundant, as you should get
exactly the same answer by readlink /etc/localtime -- and if you do
not get the same answer, you have an inconsistency. /etc/localtime
obviously "wins" for the actual clock (as that's what programs are
reading), but you presumably get the /etc/timezone value in some
"system configuration tool" packages which read /etc/timezone first.

https://codesearch.debian.net/perpackage-results/%2Fetc%2Ftimezone
shows a fair number of hits, but it's actually not so bad: as
/etc/timezone is a Debianism and /etc/localtime the distro-agnostic
standard, a lot of software which isn't Debian specific already looks
at both and only falls back to /etc/timezone if /etc/localtime does
not exist. A desktop installation boots fine and with the correct
time/zone after removing /etc/timezone.

If you are generally open to the idea, I can look through the above
codesearch results more closely to see which packages need fixing,
file bugs, and block this bug on those. But as that's quite some work,
I'd first like to discuss this with you.

Thanks!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature