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 -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A