[arch-dev-public] filesystem package

Sébastien Luttringer seblu at seblu.net
Tue Jan 29 08:18:28 EST 2013


On Tue, Jan 29, 2013 at 1:31 PM, Allan McRae <allan at 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


More information about the arch-dev-public mailing list