Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread Mike Gilbert
On Sun, Mar 21, 2021 at 11:06 PM Thomas Deutschmann  wrote:
>
> On 2021-03-22 03:06, Mike Gilbert wrote:
> > Based on that commit message, it looks systemd switched to looking at
> > the symlink target instead of /etc/timezone well *after* some major
> > distro started using a symlink for /etc/localtime. I suspect Kay
> > Sievers noticed that the content of /etc/timezone and /etc/localtime
> > were redundant on his development machine, and added a TODO entry to
> > eliminate the redundant /etc/timezone file.
> >
> > In other words, this isn't a case of systemd forcing distros to
> > symlink /etc/localtime; they were already doing that anyway.
>
> I just downloaded and tested some old distributions:
>
> Debian 9 was the first Debian release with systemd. Because of systemd,
> /etc/localtime became a symlink. In Debian 8 or when you install Debian
> 9 without systemd, it is a regular file.
>
> Ubuntu 12.04.5 is the same: No systemd, /etc/localtime is a regular
> file. Once they moved to systemd it became a symlink.
>
> In Fedora 17, which is already using systemd but a version before linked
> commit, /etc/localtime is also a regular file. But once Fedora upgraded
> to >=systemd-190 it became a symlink.

Thanks for looking into it. I wonder how Kay's system ended up that
way then. Just a curiosity.

> That's why from my P.O.V. this is clearly caused by systemd. But does
> this matter?

You're the one who brought it up; I'm not sure what the point of that
was, other than to complain about systemd.



Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread Thomas Deutschmann
PS: Even Debian is mentioning "to follow systemd" when they updated 
their tzdata package end of 2015, https://bugs.debian.org/803144.




OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread Thomas Deutschmann

On 2021-03-22 03:06, Mike Gilbert wrote:

Based on that commit message, it looks systemd switched to looking at
the symlink target instead of /etc/timezone well *after* some major
distro started using a symlink for /etc/localtime. I suspect Kay
Sievers noticed that the content of /etc/timezone and /etc/localtime
were redundant on his development machine, and added a TODO entry to
eliminate the redundant /etc/timezone file.

In other words, this isn't a case of systemd forcing distros to
symlink /etc/localtime; they were already doing that anyway.


I just downloaded and tested some old distributions:

Debian 9 was the first Debian release with systemd. Because of systemd, 
/etc/localtime became a symlink. In Debian 8 or when you install Debian 
9 without systemd, it is a regular file.


Ubuntu 12.04.5 is the same: No systemd, /etc/localtime is a regular 
file. Once they moved to systemd it became a symlink.


In Fedora 17, which is already using systemd but a version before linked 
commit, /etc/localtime is also a regular file. But once Fedora upgraded 
to >=systemd-190 it became a symlink.


That's why from my P.O.V. this is clearly caused by systemd. But does 
this matter? I doubt that systemd will even think about removing what I 
believe to be a false warning when systemd detects that /etc/localtime 
is a regular file. So let's focus on dealing with the fallout...



--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread Mike Gilbert
On Sat, Mar 20, 2021 at 11:37 AM Andreas K. Huettel
 wrote:
>
> Hi all,
>
> why do we *copy* the timezone file to /etc/localtime, instead of symlinking 
> it like everyone else?
>
> 1) Our handbook recommends:
>
> echo "Europe/Brussels" > /etc/timezone
> emerge --config sys-libs/timezone-data
>
> which is effectively doing
>
> echo "Europe/Brussels" > /etc/timezone
> cp -f /usr/share/zoneinfo/Europe/Brussels /etc/localtime
>
> 2) Most other distros seem to just do
>
> ln -sf /usr/share/zoneinfo/Europe/Brussels /etc/localtime
>
> and use the link content as timezone name (this is also what is required by 
> systemd).
>
> Does anyone remember the reason for 1) ? Or is that lost in history?

I think the most obvious reason would be to support late-mounting of
/usr, after the system clock has been reset with a UTC offset on boot.
To make this work, the /etc/localtime file would need to be available
when the hwclock init script runs.

These days, I suspect there are not many users running systems with a
hardware clock in local time, and a separate /usr filesystem, and no
initramfs to mount /usr early.

I created a PR to adjust the logic in timezone-data to promote
symlinks for new installs, while keeping regular files in place for
existing users.

https://github.com/gentoo/gentoo/pull/20050

If we added some logic to detect if /usr is a separate filesystem, we
could possibly be even more aggressive about this. But I'm not sure I
want to rock the boat that much in one commit.



Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread Mike Gilbert
On Sun, Mar 21, 2021 at 7:58 PM Thomas Deutschmann  wrote:
>
> On 2021-03-20 16:37, Andreas K. Huettel wrote:
> > 2) Most other distros seem to just do
>
> No, not most distros are doing that. systemd is forcing that downstream
> (the result is the same)!
>
> It was added via
> https://github.com/systemd/systemd/commit/92c4ef2d357baeef78b6f82f119b92f7ed12ac77
> without mentioning a reason.

Based on that commit message, it looks systemd switched to looking at
the symlink target instead of /etc/timezone well *after* some major
distro started using a symlink for /etc/localtime. I suspect Kay
Sievers noticed that the content of /etc/timezone and /etc/localtime
were redundant on his development machine, and added a TODO entry to
eliminate the redundant /etc/timezone file.

In other words, this isn't a case of systemd forcing distros to
symlink /etc/localtime; they were already doing that anyway.



Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread Thomas Deutschmann

On 2021-03-20 16:37, Andreas K. Huettel wrote:

2) Most other distros seem to just do


No, not most distros are doing that. systemd is forcing that downstream 
(the result is the same)!


It was added via 
https://github.com/systemd/systemd/commit/92c4ef2d357baeef78b6f82f119b92f7ed12ac77 
without mentioning a reason.



--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Specifying locale in ebuild

2021-03-21 Thread Remco Rijnders
On Sun, Mar 21, 2021 at 08:43:47PM +0100, Michał wrote in 
<3d0e94fee25354fec5284e2edb5c79473c526cd2.ca...@gentoo.org>:

Can I somehow enforce the locale to be used in the ebuild? I've tried running
the test with the default C locale and the test also fails with this setting.


Try forcing C.UTF-8


Very nice, that seems to do the trick! Muito obrigado!

Remmy



Re: [gentoo-dev] Specifying locale in ebuild

2021-03-21 Thread Michał Górny
On Sun, 2021-03-21 at 13:21 -0400, Remco Rijnders wrote:
> I hope this is the appropiate place to ask this question as I do not see many
> questions of this kind on this list...
> 
> Recently I received a bug report for a package of which I am the listed proxy
> maintainer: https://bugs.gentoo.org/772908
> 
> Having looked into this, it seems the packages Makefile allows for tests to be
> run which feeds a set of input to the 'remind' executable and compares the
> resulting output against an included textfile. For the test to run 
> successfully,
> the Makefile assumes the locale en_US.utf-8 to be available. On the build
> environment by agostino's tinderbox, this locale is not available and thus the
> test fails and hence the bug report. While I know the impact of this bug is 
> very
> minor, I'd still like to fix it, but am unsure on how to best do this.
> 
> Can I somehow enforce the locale to be used in the ebuild? I've tried running
> the test with the default C locale and the test also fails with this setting. 
> Or
> should I ask upstream to provide test files for a C locale setting? Or should 
> I
> skip these tests completely, or mark the bug as WONTFIX? What would you advice
> as the best approach for dealing with this?

Try forcing C.UTF-8

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] rfc: usrmerge script

2021-03-21 Thread William Hubbs
On Sun, Mar 21, 2021 at 08:08:00PM +0100, Luigi Mantellini wrote:
> there are some typos at lines 93, 94 and 95 (run_cmd instead run_command).
> 
> ciao
> 
> luigi
 
 Hi Luigi,

Thanks for catching these, all instances of run_cmd are now changed to
run_command.

Thanks,

William


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: usrmerge script

2021-03-21 Thread William Hubbs
On Sun, Mar 21, 2021 at 01:00:01PM -0500, Matthias Maier wrote:
> Hi William,
> 
> I have migrated my system to a merged /usr a while ago.
> 
> In addition to moving everything to /usr and setting up symlinks, the
> main thing I had to do was to set up a /etc/portage/bashrc hook for
> post_src_install() that would move everything into /usr.
> 
> Do we have native support in portage for this now?

From what I know, you don't need that hook. The ebuilds handle this now
by using the split-usr use flag, so if you add this to
/etc/portage/make.conf you should be ok.

USE="${USE} -split-usr"

Let me know if that isn't the case.

I'm not exactly sure what portage will do without your hook though. What
happens if you remove your hook then some ebuild tries to install
something in /bin for example? I would argue that, if /bin resolves to a
path, portage should just follow the symlink and install where the
symlink points.  I base this argument on the return of `test -d` for
this situation.

```
$ ln -s /usr/bin foo
$ [ -d foo ] && echo "foo is a path"
```

Thanks,

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: usrmerge script

2021-03-21 Thread Luigi Mantellini
there are some typos at lines 93, 94 and 95 (run_cmd instead run_command).

ciao

luigi

On Sun, Mar 21, 2021 at 7:00 PM Matthias Maier  wrote:
>
> Hi William,
>
> I have migrated my system to a merged /usr a while ago.
>
> In addition to moving everything to /usr and setting up symlinks, the
> main thing I had to do was to set up a /etc/portage/bashrc hook for
> post_src_install() that would move everything into /usr.
>
> Do we have native support in portage for this now?
>
> Best,
> Matthias
>
>
> On Sun, Mar 21, 2021, at 12:39 CDT, William Hubbs  wrote:
>
> > All,
> >
> > the following is a script which will migrate a Gentoo system to the usr
> > merge layout. This is similar to the unsymlink-lib tool used to migrate
> > a system  from the 17.0 to the 17.1 profiles.
> >
> > I'm attaching it here to get some comments before I package it, so
> > please let me know if I have missed something.
> >
> > Thanks,
> >
> > William
>


-- 
Luigi 'Comio' Mantellini
R - Software
Industrie Dial Face S.p.A.
Via Canzo, 4
20068 Peschiera Borromeo (MI), Italy

Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
web: www.idf-hit.com
mail: luigi.mantell...@idf-hit.com



Re: [gentoo-dev] rfc: usrmerge script

2021-03-21 Thread Matthias Maier
Hi William,

I have migrated my system to a merged /usr a while ago.

In addition to moving everything to /usr and setting up symlinks, the
main thing I had to do was to set up a /etc/portage/bashrc hook for
post_src_install() that would move everything into /usr.

Do we have native support in portage for this now?

Best,
Matthias


On Sun, Mar 21, 2021, at 12:39 CDT, William Hubbs  wrote:

> All,
>
> the following is a script which will migrate a Gentoo system to the usr
> merge layout. This is similar to the unsymlink-lib tool used to migrate
> a system  from the 17.0 to the 17.1 profiles.
>
> I'm attaching it here to get some comments before I package it, so
> please let me know if I have missed something.
>
> Thanks,
>
> William



[gentoo-dev] rfc: usrmerge script

2021-03-21 Thread William Hubbs
All,

the following is a script which will migrate a Gentoo system to the usr
merge layout. This is similar to the unsymlink-lib tool used to migrate
a system  from the 17.0 to the 17.1 profiles.

I'm attaching it here to get some comments before I package it, so
please let me know if I have missed something.

Thanks,

William

#!/bin/bb
# shellcheck disable=SC2039 shell=sh

rollback_path=/var/usrmerge-rollback

check_internal_commands() {
for cmd in cp ln; do
[ "$(command -v "${cmd}")" = ${cmd} ] && continue
printf 'busybox does not include the %s command internally\n' 
"${cmd}"
return 1
done
return 0
}

check_root() {
 [ "$(id -u)" = 0 ] && return 0
 printf 'This script must be run by root\n'
 return 1
}

run_command() {
local cmd
[ -n "${dryrun}" ] && cmd="echo"
${cmd} "$@" || exit
return 0
}

setup_rollback() {
if [ -e "${rollback_path}" ]; then
printf '%s already exists\n' "${rollback_path}"
printf 'please remove it before continuing\n'
return 1
fi
printf 'Creating %s to allow rollbacks\n' "${rollback_path}"
run_command mkdir "${rollback_path}"
run_command mkdir "${rollback_path}/usr"
local dir
for dir in /bin /lib* /sbin; do
run_command cp -a "${dir}" "${rollback_path}"
done
for dir in /usr/bin /usr/lib* /usr/sbin; do
[ "${dir}" = /usr/libexec ] && continue
run_command cp -a "${dir}" "${rollback_path}/usr"
done
return 0
}

action_finish() {
run_command rm -fr "${rollback_path}"
return 0
}

action_help() {
local cmd
cmd="$(basename "${0}")"
printf 'usage: %s -h\n' "${cmd}"
printf '   %s [-d] -f|-m|-r\n' "${cmd}"
printf '\n'
printf '-h | --help  - displays this message\n'
printf '-d | --dry-run   - show what would be done\n'
printf '-f | --finish- remove the rollback data\n'
printf '-m | --merge - perform the usr merge\n'
printf '-r | --roll-back - attempt to undo the usr merge\n'
return 0
}

action_merge() {
if [ -L /bin ] || [ -L /sbin ]; then
printf 'The /usr merge has been completed on this system\n'
return 0
fi

local dir
for dir in /lib*; do
[ -L "${dir}" ] || continue
printf '%s is a symbolic link.\n' "${dir}"
printf 'This means you have not migrated to the 17.1 profiles 
yet\n'
printf 'please do so before running this script\n'
return 1
done

setup_rollback || return

# copy root directories to /usr counterparts and create
# the /usr merge compatibility symlinks
for dir in /bin /lib* /sbin; do
run_command cp -a -i "${dir}"/* /usr/"${dir}"
run_command rm -rf "${dir}"
run_command ln -snf usr/"${dir}" "${dir}"
done

# merge /usr/sbin into /usr/bin
run_cmd cp -a -i /usr/sbin/* /usr/bin
run_cmd rm -fr /usr/sbin
run_cmd ln -snf bin /usr/sbin
return 0
}

action_rollback() {
if [ ! -d "${rollback_path}" ]; then
printf '%s does not exist, unable to roll back\n' 
"${rollback_path}"
return 1
fi
local dir rollback_dir
for dir in /bin /lib* /sbin /usr/bin /usr/lib* /usr/sbin; do
[ "${dir}" = /usr/libexec ] && continue
rollback_dir="${rollback_path}/${dir}"
[ -d "${rollback_dir}" ] && continue
printf 'Unable to perform rollback, %s is missing\n' 
"${rollback_dir}"
return 1
done
for dir in /bin /lib* /sbin ; do
rollback_dir="${rollback_path}/${dir}"
run_cmd  rm -fr "${dir}"
run_cmd cp -a "${rollback_dir}" /
done
for dir in /usr/bin /usr/lib* /usr/sbin; do
[ "${dir}" = /usr/libexec ] && continue
rollback_dir="${rollback_path}/${dir}"
run_cmd  rm -f "${dir}"
run_cmd cp -a "${rollback_dir}" /usr
done
return 0
}

main() {
local dryrun finish merge rollback
while [ $# -gt 0 ]; do
case $1 in
-d|--dry-run)
dryrun=1
;;
-h|--help)
action_help
return 0
;;
-f|--finish)
finish=1
;;
-m|--merge)
merge=1
;;

[gentoo-dev] Specifying locale in ebuild

2021-03-21 Thread Remco Rijnders

I hope this is the appropiate place to ask this question as I do not see many
questions of this kind on this list...

Recently I received a bug report for a package of which I am the listed proxy
maintainer: https://bugs.gentoo.org/772908

Having looked into this, it seems the packages Makefile allows for tests to be
run which feeds a set of input to the 'remind' executable and compares the
resulting output against an included textfile. For the test to run successfully,
the Makefile assumes the locale en_US.utf-8 to be available. On the build
environment by agostino's tinderbox, this locale is not available and thus the
test fails and hence the bug report. While I know the impact of this bug is very
minor, I'd still like to fix it, but am unsure on how to best do this.

Can I somehow enforce the locale to be used in the ebuild? I've tried running
the test with the default C locale and the test also fails with this setting. Or
should I ask upstream to provide test files for a C locale setting? Or should I
skip these tests completely, or mark the bug as WONTFIX? What would you advice
as the best approach for dealing with this?

Many thanks for any and all suggestions!

Regards,

Remco



Re: [gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository

2021-03-21 Thread Kaibo Ma
>1. We need to be able to tell the build system that it should only
>lookup artifacts from a particular repository, the system wide one.

I don't think this would be a big problem.
For ebuilds, they can just enable offline mode which would restrict
maven/gradle from using remote artifacts.

As gradle/maven dependency caches are on a per-user basis,
the portage user would not encounter issues such as using a
previously fetched artifact from the cache.

>2. We need to be able to tell the build system to install it's artifacts
>in a particular local repository, nowhere else.

This would be hard for maven I think. But for gradle,
init scripts could be installed to GRADLE_HOME/init.d/
by eselect-gradle which will add the local repository to
publishing, plugins, and dependencies repos.

See https://docs.gradle.org/current/userguide/init_scripts.html.


Re: [gentoo-dev] [RfC] Supporting Maven/Gradle build systems by installing to a local maven repository

2021-03-21 Thread Florian Schmaus
On 15.03.21 14:02, Kaibo Ma wrote:
> 3. ERRATA
> 
> The local maven repository would not be a good fit since it is on a
> per-user basis (~/.m2). The correct way would be to define a path for
> installing (such as /usr/share/.m2), and pass that to build tools as a
> URL (file:///usr/share/.m2).

Correct, the user-local maven repository is not suitable.

I have been thinking about how to support "modern" Java-ish applications
for a long time. One requirement is a system-wide maven repository. But
you also need support from the build system, e.g. Gradle or Maven:


1. We need to be able to tell the build system that it should only
lookup artifacts from a particular repository, the system wide one. For
example

gradle --exlusive-maven-repository "${SYSTEM_WIDE_MAVEN_REPO}"

2. We need to be able to tell the build system to install it's artifacts
in a particular local repository, nowhere else. For example

gradle publishToMavenLocal --into 


Given a Maven repositories structure, especially considering a Maven
repositories metadata, I believe this needs some effort if 
is somewhere under ${D}. But nothing that is impossible to solve.

And, I think it is clear that this *requires* support from the build
systems. That is, any approach that is based on patching build system
configuration to achieve similar results in fragile and hence not
sustainable.

I think it would be beneficial to team-up with other distrbutions. Even
non source-based ones, like Debian, would benefit from an established
and standardized system-wide Maven repository.

But in summary, this is not a trivial task and it requires cooperation
from and coordination with from the build systems. But if we want to
continue packaging source-based Java-ish applications, that are not
simply fat Jars, then we would need something like this. Hence I'd
really like to see it one day.

- Florian




[gentoo-portage-dev] [PATCH] PORTAGE_NICENESS: Consider autogroup scheduling

2021-03-21 Thread Florian Schmaus
With Linux's autogroup scheduling feature (CONFIG_SCHED_AUTOGROUP)
setting a nice value on a per-process base has only an effect for
scheduling decisions relative to the other threads in the same
session (typically: the same terminal window). See the section "The
nice value and group scheduling" in the sched(7) man page.

Basically this means that portage "just" setting the nice value, has
no effect in presence of autogroup scheduling being active (which is
probably true for most (desktop) user systems).

This commit changes emerge to set the autogroup's nice value, instead
of the processes' nice value, in case autogroups are present (detected
by the existence of /proc/self/autogroup). The tricky part about
autogroup nice values is that we want restore the orignal nice value
once we are finished. As otherwise, the session, e.g. your terminal,
would continue using this value, and so would subsequently executed
processes. For that we use Python's atexit functinaly, to register a
function that will restore the orignal nice value of the autogroup.

Bug: https://bugs.gentoo.org/777492
Signed-off-by: Florian Schmaus 
---
 lib/_emerge/actions.py | 46 +++---
 1 file changed, 39 insertions(+), 7 deletions(-)

diff --git a/lib/_emerge/actions.py b/lib/_emerge/actions.py
index 239bf6f476d1..8f6e7c51b6dc 100644
--- a/lib/_emerge/actions.py
+++ b/lib/_emerge/actions.py
@@ -1,6 +1,7 @@
 # Copyright 1999-2020 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
+import atexit
 import collections
 import logging
 import operator
@@ -14,6 +15,7 @@ import textwrap
 import time
 import warnings
 from itertools import chain
+from pathlib import Path
 
 import portage
 portage.proxy.lazyimport.lazyimport(globals(),
@@ -2632,13 +2634,43 @@ def apply_priorities(settings):
nice(settings)
 
 def nice(settings):
-   try:
-   os.nice(int(settings.get("PORTAGE_NICENESS", "0")))
-   except (OSError, ValueError) as e:
-   out = portage.output.EOutput()
-   out.eerror("Failed to change nice value to '%s'" % \
-   settings.get("PORTAGE_NICENESS", "0"))
-   out.eerror("%s\n" % str(e))
+   autogroup_file = Path("/proc/self/autogroup")
+
+   nice_value : str = settings.get("PORTAGE_NICENESS", "0")
+
+   if not autogroup_file.is_file():
+   # Autogroup scheduling is not enabled on this system,
+   # continue using good ol' os.nice().
+   try:
+   os.nice(int(nice_value))
+   except (OSError, ValueError) as e:
+   out = portage.output.EOutput()
+   out.eerror("Failed to change nice value to '%s'" % \
+  settings.get("PORTAGE_NICENESS", "0"))
+   out.eerror("%s\n" % str(e))
+   return
+
+   with autogroup_file.open('r+') as f:
+   line = f.readline()
+   original_autogroup_nice_value = line.split(' ')[2]
+
+   # We need to restore the original nice value of the
+   # autogroup, as otherwise the session, e.g. the
+   # terminal where protage was executed in, would
+   # continue running with that value.
+   atexit.register(
+   lambda value: autogroup_file.open('w').write(value),
+   original_autogroup_nice_value
+   )
+
+   try:
+   f.write(nice_value)
+   except (OSError) as e:
+   out = portage.output.EOutput()
+   out.eerror("Failed to change nice value to '%s'" % \
+  settings.get("PORTAGE_NICENESS", "0"))
+   out.eerror("%s\n" % str(e))
+
 
 def ionice(settings):
 
-- 
2.26.3




Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread James Le Cuirot
On Sun, 21 Mar 2021 05:18:52 +0100
Ulrich Mueller  wrote:

> > On Sat, 20 Mar 2021, William Hubbs wrote:  
> 
> > /etc/localtime should definitely be a symlink to the proper file in
> > /usr/share/zoneinfo.  
> 
> > This works fine if /usr is on a separate partition *and* you are using
> > an initramfs. The only time it doesn't work is if /usr is separate
> > without using an initramfs.  
> 
> > Council decided years ago that we don't support separate /usr without
> > an initramfs, but we haven't completed that transition yet.  
> 
> Which doesn't imply that we deliberately break things.

How about making emerge --config dynamic, copying if it's on a
different partition and symlinking if it's not? You can't accurately
determine the use of an initramfs but at least this is closer to what
we want.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgppd9SmOxjcX.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread Ulrich Mueller
> On Sun, 21 Mar 2021, Alec Warner wrote:

> https://bugs.gentoo.org/737914 seems to imply for some upstreams, it
> being a file is not a valid option anymore?

> (I'm ignoring the logic of that decision of course, but this was the
> original reason this was raised.)

Indeed, that's a strange design decision. It also violates the principle
of least surprise, because nobody will expect a symlink to behave any
different from a literal copy of the file (or even from a hardlink) when
reading it.

Ulrich


signature.asc
Description: PGP signature