requires(post) on coreutils
Colin Walters
walters at verbum.org
Thu Nov 20 19:49:56 UTC 2008
2008/11/20 Jesse Keating <jkeating at redhat.com>:
> On Thu, 2008-11-20 at 14:19 -0500, Colin Walters wrote:
>> How could one even propose using shell script without coreutils
>> installed? What are you going to do in that script?
>>
>> Requires(post): coreutils strikes me as just an exercise in bloating
>> the dependency graph. This mindset of putting core OS bits and random
>> third party applications in the same mental category of "package" and
>> applying the exact same rules to them is just wrong.
>
> That's the fun thing about %post, it doesn't have to be bash. The fact
> that it is for most people is just implementation details. People could
> write their post scripts in csh, lua, whatever.
But there's clearly a default, which is shell script. And in
particular bash. In any case do we really want to encourage people
writing their %post scripts in lua or whatever random language they
like? I don't think we do. That will fragment the community of
people who can modify a package.
> The point is that the
> package installation system needs to know what your package needs before
> it's scripts can be ran. Trying to set some arbitrary level of "OS
> bits" and "applications" is doomed to fail.
We have that in comps, in particular say everything in core/mandatory.
In the first phase, lay all that stuff down since it's not optional.
I'd be shocked if there weren't circular dependencies here that took
special handling in the installer anyways.
> We have a system that
> handles the ordering for us, it just needs a few hints along the way.
Yes, but the problem is that we're *introducing bugs* and wasting the
time of the people who are trying to package things higher up in the
stack.
I wouldn't care at all about this if people wanted to mess around with
the core OS packages and add dependencies, but if I get a bug about
this in one of my packages it'll be 5 minutes down the drain that
could have been spent somewhere more useful.
More information about the fedora-devel-list
mailing list