Le 12/09/2017 à 21:27, Giancarlo Razzolini a écrit :

Em setembro 12, 2017 14:58 Andreas Radke escreveu:

...

New filesystem/systemd packages in testing have changed the way we create system users/groups. That's done now via systemd itself or using a systemd hook. So every package that needs certain user/group existent or certain UID/GID to install its file will depend on systemd to be installed on the system.

Check https://bugs.archlinux.org/task/55492 - systemd is now part of base-devel.

I think it's not consequent not to move it to base group. It's the only init system we support and therefor should be expected to be installed on every Arch installation from now on. User/group creating packages will need it installed in any way.

Opinions?

Hi Andreas,

We have discussed this on IRC and this has been a recurring theme over the years.

So this finally made it to adp one way. Let’s start the official discussion about it.

I see two main things that derive from this:

1) base is assumed or not? I know some developers don't assume base and list it on their packages dependencies.

We have been telling our users that base is assumed since at least 2009 [0]

Yes, but in fact most of us do not assume base as installed indeed. Even Andreas just proved us that he doesn’t have base installed on its system (at least systemd-sysvcompat is missing). As far as I’m concerned, I have at least 6 different machines, and none of them have the full base. Also, it’s not assumed by devtools in contrary to base-devel. Finally, I would say that the base group, as well as most other groups, are helpers to get things done at install time. But those should not be assumed.

2) The second thing that arises from the first is a broader question which is what do we consider a minimal arch installation?

If the answer to this question is base, then we certainly *must* have systemd on it. And we can discuss trimming it down, because I think that base has some packages that shouldn't be there such as, netctl and dhcpcd (I use both).

If the answer is not base, then we should have something like a base-system group which contains the bare minimum, like linux, glibc, pacman, systemd and its dependencies.

That. We don’t need to list dependencies in the group itself (we don’t do that for base), especially because you don’t want to track dependencies changes of systemd also in the group. Or as per Sebastien idea, we could have a `base` or `arch` or -system package depending on the required packages. Bonus: you can change what’s in the minimal installation without having to tell users that this package is now in the group or this one isn’t anymore, pacman will handle that. ;) Regards, Bruno

Em setembro 14, 2017 16:17 Eli Schwartz escreveu:

And now we are even getting things like https://bugs.archlinux.org/task/55635 which attempt to justify yet more such bugreports based on the mere fact that this a-d-p thread exists, while assuming the answer you all decide upon.

Now I'm regretting that this was started on arch-devel-public.

This has finally gone from confusing to downright annoying; after all the times this was discussed here and on arch-general etc. it seems the community has become interested enough for the self-appointed dependency police to start campaigning. Hopefully I am wrong...

Their only tool is the bug tracker. This does not give them permission to file a bug for something that does not exist (yet?). For all the other users listening to this, don't open bug requests like that one. Thank you for dealing with those in the meantime Eli and Doug.

I really want to see a standard policy for this. Assuming my opinion holds any weight whatsoever, I'd like to see a base-system (or a trimmed-down base) in preference to adding dependencies like glibc/bash to the vast majority of packages... I also agree that a metapackage is nicer than a group. If we are going to stick to an official policy for a base system, people should not be able to remove parts on a whim or neglect parts that become part of the base system when the next initscripts-to-systemd migration or whatever happens (and then complain that things break).

We have been telling users on the install guide and on the makepkg page for a long time that base is assumed. And some devs/tus list packages on base, but from what I saw, the majority do not. I think this should be fixed by a bare bones "essentials" metapackage and we should get over with this and move on. Cheers, Giancarlo Razzolini

Am Tue, 12 Sep 2017 22:02:54 +0200 schrieb Sébastien Luttringer <seblu@seblu.net>:

Hello,

Systemd is in the base group since October 2012. Not sure to understand if your problem is about base or base-devel. Most of our packages moved to systemd-sysusers. Would make sense to not have filesystem do the same?

Regards,

It's in the core repo but not in "base" group. root@laptop64:/root # LANG=C pacman -Qi systemd | grep Groups Groups : base-devel And chroots and Arch installation media simply install the full base group. So far systemd is not included and we now have a problem with user/group creation. -Andy

Morning. I've cleaned systemd-sysvcompat long time ago from all my systems. I didn't know it is still alive and is meant to pull in main systemd. Lately cups-filters failed to install when building in a clean chroot due to missing "lp" group. Having systemd-sysvcompat in base should have pulled in systemd and allow "lp" group creation. Maybe this is another trigger of the systemd bug. We should continue talking on the list. Maybe we should stop splitting systemd and simply make it part of "base" group to make sure all Arch users have all its parts installed. -Andy

Sébastien Luttringer <seblu@seblu.net> hat am 12. September 2017 um 22:14 geschrieben:

On Tue, 2017-09-12 at 22:09 +0200, Andreas Radke wrote:

...

Am Tue, 12 Sep 2017 22:02:54 +0200 schrieb Sébastien Luttringer <seblu@seblu.net>:

...

Hello,

Systemd is in the base group since October 2012. Not sure to understand if your problem is about base or base-devel. Most of our packages moved to systemd-sysusers. Would make sense to not have filesystem do the same?

Regards,

It's in the core repo but not in "base" group.

root@laptop64:/root # LANG=C pacman -Qi systemd | grep Groups Groups : base-devel

And chroots and Arch installation media simply install the full base group. So far systemd is not included and we now have a problem with user/group creation.

systemd-sysvcompat is in base group, and it pulls systemd.Do a pacstrap, you will see systemd installed. Devtools use base-devel, which prevent linux or others non necessary packages to be pulled to only build packages.

Sébastien "Seblu" Luttringer

On Wed, 2017-09-13 at 07:35 +0200, andyrtr@archlinux.org wrote:

I've cleaned systemd-sysvcompat long time ago from all my systems. I didn't know it is still alive and is meant to pull in main systemd.

pacstrap, the arch-bootstrap tarball and the Arch installation media already have systemd pulled, so far, I didn't notice a change. Since filesystem use systemd-sysusers to initialize our users/groups, it should deps on systemd. It was suggested by Evangelos in FS#55492, but this create a circular deps, because filesystem <- systemd <- glibc <- filesystem. Maybe it's a better solution to make gblic drop filesystem dep and add a systemd dep to filesystem. However, put systemd in the base-devel make also sense like having glibc or filesystem.

Lately cups-filters failed to install when building in a clean chroot due to missing "lp" group. Having systemd-sysvcompat in base should have pulled in systemd and allow "lp" group creation. Maybe this is another trigger of the systemd bug. We should continue talking on the list.

I don't think lp is a systemd bug, but a mistake from my side. I forgot to add it or to ask for moving it like i did for mlocate (FS#53539) or rfkill (FS#53525). It looks like the lp group is tied to cups and not multiple packages; do you think it should be moved to cups package? About the systemd bug, Lennart just pushed a fix which should land in v235. In the mean time, I think to push a new version with root and nobody defined in files to not have sshd segfault on new installations.

Maybe we should stop splitting systemd and simply make it part of "base" group to make sure all Arch users have all its parts installed.

Groups are a shortcut to pull a collection of packages. They are not designed to guarantee a set of packages remain installed. Your removal of systemd- sysvcompat is one example. If we want to have a set of package installed on all our Arch, we should use a base package which pull these packages. Cheers,

On 2017-09-19 18:40, Sébastien Luttringer wrote:

On Thu, 2017-09-14 at 14:08 +0200, Bartłomiej Piotrowski wrote:

...

My main problem with recent changes to filesystem package is that there is no clear benefits of using sysusers to do the job. Can anyone enlighten me, or is it a change for the sake of change?

This is a step forward to have an Arch working with a transient /etc, as all required users/groups will be created by systemd-sysusers.

Do you plan to also fix ca. 1000 other packages in repositories that ship files in /etc/?

I didn't find a good reason to refuse to implement this BR and with hindsight it's a smart move.Ok, that's not a revolution, but « a change for the sake of change»? You are harsh!

It's a valid question though.

...

From top of my head, it caused issues with pacstrapping with testing, dependency cycle, OpenSSH and cups, and I'm certain I missed something. You are mixing issues from several changes in filesystem and not related systemd-sysusers.So far the solutions looks good to me. Do you want I sum them up?Is there one in particular issue you want to discuss outside the bug report?

Because I'm talking about the general process of changes that have been done and not particular revision. Even if everything looks fine now, it's still something that should have been sent to arch-dev-public as a heads up instead of discussing it here only because I expressed concerns on the bug tracker after the party was over (especially given that you are hard to catch on IRC).

...

If the gain is ditching few lines of bash from install scriplet, we have wrong priorities… What was the gain to change ${CFLAGS} into $CFLAGS to our master plan to control the universe?

Whatever you're trying to prove here.