On 12/22/2014 11:55 AM, Vít Ondruch wrote:
Dne 22.12.2014 v 10:46 Ralf Corsepius napsal(a):
> On 12/22/2014 10:15 AM, Vít Ondruch wrote:
>> Dne 20.12.2014 v 18:55 Jason L Tibbitts III napsal(a):
>>> So I stumbled upon this blog post:
>>> and there are a few things in there which seem like they might be good
>>> to incorporate into our packaging guidelines, or perhaps into our
>>> tooling (rpm up through mock and koji). Random thoughts follow.
>>> Dependency minimization is obviously a big one; we struggle with this.
>>> Build-time dependency minimization is far more difficult.
>> First step is to have really minimal build root. For me that means to
>> get rid of Perl from it. I hope that Perl guys are slowly working on
>> fixing their packages.
> To me, what you say is a religious statement, which doesn't have any
> immediate benefits, but already has shown its harmful nature because
> is already is causing malfunctions.
As well as broken Perl caused malfunctions of PPC builders.
And? This is Red Hat's problem. I think hardly anybody outside of RH
these days has access to PPC-HW, so if RH wants to support the PPC, RH
will have to fix the bugs being encountered themselfs.
What Red Hat's crusade (That's what I call it) against Perl has done at
other places (replacing fully functional tools with half functional
replacements) is RH to cause bugs - I regret but this is's a situation,
which really annoys and upsets me.
> On a wider scope, I'd agree to gradually minimizing
> buildroots, which would mean to gradually remove implicit package deps
> and making package requirements more explicit.
> So, why not remove all scripted languages from buildroots and require
> them to be explicitly BR:'d and R:'ed?
I agree with these of course. And I'd go one step further and remove
also gcc, gcc-c++ and make.
Except that I'd consider this to be
non-implementable and non-realistic
in short terms, I'd not be opposed to this. That's why I am taking about
These are not needed for most of packages
for scripting languages.
Right, but they are BR:'s of all packages most and
R:'s of many
packages. Also, perl is a requirement of autotools-based packages => So,
the win will be not be as overwhelming as you probably assume.