On Sun, Jan 27, 2013 at 1:55 AM, Allan McRae wrote:

Anyway, I say we can just remove post_install from filesystem and reduce the dependencies to only iana-etc

Yes please. This has long been on my low-priority TODO.

, and then make glibc depend on filesystem. We can assume coreutils and bash are installed before an upgrade of filesystem.

Yup. For post_upgrade we can depend on 'base' being installed.

Lets see what is in filesystem's post_install:

post_install() { [ -f var/log/lastlog ] || : >var/log/lastlog

Either just remove (not sure why it is needed, didn't check), or move to shadow as you propose.

[ -f var/log/wtmp ] || : >var/log/wtmp [ -f var/log/btmp ] || { : >var/log/btmp && chmod 600 var/log/btmp; }

Not needed. Done by /usr/lib/tmpfiles.d/systemd.conf

# workaround for bug #7194 # readded due to bug #9465 # please do not remove! chmod 1777 var/spool/mail tmp var/tmp }

The chmod part can be removed (despite the warning). It was initially a bug in pacman and then the installer. Given pacman has been fixed for years and we just use "pacman -r" for the installer, there is no need for that. This is entirely the wrong place to fix this non-existent bug.

Great!

That leaves the initialising of log files. I guess the lastlog one should be moved to the shadow package. Definitely not the job of filesystem. I am not sure what package should do the wtmp and btmp ones. Anyone know?

As stated above: just remove it. -t

Tom Gundersen wrote:

...

, and then make glibc depend on filesystem. We can assume coreutils and bash are installed before an upgrade of filesystem.

Yup. For post_upgrade we can depend on 'base' being installed.

Why are you assuming anything? If those packages are needed, why not make them explicit dependencies? I don't see how that turned into depending on all of "base" to be installed either. Regards, Xyne

On Tue, Jan 29, 2013 at 1:31 PM, Allan McRae wrote:

On 29/01/13 22:24, Xyne wrote:

...

...

Yup. For post_upgrade we can depend on 'base' being installed.

Why are you assuming anything? If those packages are needed, why not make them explicit dependencies?

I don't see how that turned into depending on all of "base" to be installed either.

Because then you can not have glibc depend on filesystem and everything breaks during install - as was explained earlier in the thread.

And assuming bash and coreutils for post_upgrade is quite reasonable, given your system is in a state to run pacman...

I thougth the point was about base dependency. Using pacman deps inside pacman scripts is obvious. Except if there is strong pacman version requirement to get a depends. But we are not here. Consider that base group must be installed is a bit different. So I'm wondering, should we consider base group as : 1| a list of packages installed on a fresh installation. Implies pkg can be removed/chaned (e.g cron by fcron) or 2| a list of must have packages. Implies implicit deps in pkg. Both are impossible. If pkg can be removed, we cannot rely on this to have implicit deps on base. A group as no version, I remember an issue with the base group which have changed in testing and core application think not. So using group for point 2 can be less appropriate than a base "meta" package. If I understand correctly Allan TODO add-more-to-base-devel[1], next chroot will only needs base-devel and no more base[2]. So to programs must be able to make / make check with only base-devel package. So base should (now?) be considered only as a list of default packages on new install? Cheers, [1] https://www.archlinux.org/todo/add-more-to-base-devel/ [2] \o/ -- no more linux package -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A