So... some unintended consequences of moving /lib to filesystem. Install scriptlet can not run until filesystem is installed.
That means, glibc really should depend on filesystem, but the filesystem package is a bit "bloated":
Depends On : iana-etc bash coreutils nss-myhostname
bash, coreutils and nss-myhostname all are for the install scriptlets to run.
In fact, we are entirely saved here by a bug in pacman: nss-myhostname is provided by systemd, but pacman does not order packages correctly with provides, so systemd is not installed first at a time when install scriptlets fail...
Anyway, I say we can just remove post_install from filesystem and reduce the dependencies to only iana-etc, and then make glibc depend on filesystem. We can assume coreutils and bash are installed before an upgrade of filesystem.
Lets see what is in filesystem's post_install:
post_install() { [ -f var/log/lastlog ] || : >var/log/lastlog [ -f var/log/wtmp ] || : >var/log/wtmp [ -f var/log/btmp ] || { : >var/log/btmp && chmod 600 var/log/btmp; } # 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.
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?
Allan
On 27/01/13 10:55, Allan McRae wrote:
So... some unintended consequences of moving /lib to filesystem. Install scriptlet can not run until filesystem is installed.
FYI, this current only affects the post_install of bash, gmp and coreutils which are all texinfo installs - so there is no real issue at the moment.
On Sun, Jan 27, 2013 at 1:55 AM, Allan McRae allan@archlinux.org 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
On 27/01/13 10:55, Allan McRae wrote:
In fact, we are entirely saved here by a bug in pacman: nss-myhostname is provided by systemd, but pacman does not order packages correctly with provides, so systemd is not installed first at a time when install scriptlets fail...
Actually it is a dependency cycle being resolved alphabetically that is saving us:
warning: dependency cycle detected: warning: filesystem will be installed before its systemd dependency
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 29/01/13 22:24, Xyne wrote:
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.
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...
Allan
On Tue, Jan 29, 2013 at 1:31 PM, Allan McRae allan@archlinux.org 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
On 29/01/13 23:18, Sébastien Luttringer wrote:
On Tue, Jan 29, 2013 at 1:31 PM, Allan McRae allan@archlinux.org 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.
Do a pactree on pacman and note that both the packages removed from the filesystem dependencies are in its dependency tree...
I consider the "base" group only as an installation helper and agree we should always specify dependencies that are needed. But central packages to the system require some adjustments to ensure their installation order due to dependency cycles. There are very few packages like that - filesystem being one, particularly now the symlinks are needed for the ELF interpreter. And the only assumption being made is that coreutils and bash are installed for post_upgrade. If you do a -Qi on those packages on your system, you will see it is not possible for that to happen and your system being in a state to run a pacman update.
Allan
arch-dev-public@lists.archlinux.org