So I stumbled upon this blog post:
http://developerblog.redhat.com/2014/12/19/bootstrapping-power8-little-endia...
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. Is there any value in standardizing methods (probably using conditionals in the spec) to minimize build-time dependencies? If you have a very core package that needs the whole X stack to build one of its subpackages, maybe conditionalize the build so that you can build without that subpackage and not need X. (autoconf needs emacs? Wow.)
I think currently we have only one or two places where we absolutely require lua for scriptlets. bash is the only one I can think of, because it would otherwise need itself to install. Is there value in using it more often, for more core packages?
I wonder how many packages have additional build-time dependencies solely for running %check. Would it be reasonable to be able to separate these somehow (BuildRequires(check): foo) and to pass up disabling %check through our tooling?
- J<
Dne 20.12.2014 v 18:55 Jason L Tibbitts III napsal(a):
So I stumbled upon this blog post:
http://developerblog.redhat.com/2014/12/19/bootstrapping-power8-little-endia...
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.
Second thing is that the resulting build depends on content of build root. E.g. for Ruby, there are build or not build various extensions depending if the library is available. In theory, the dependencies should be explicitly specified by configures --with(out) flags but I am not sure if that is enough. Moreover, there is no guidelines about this to my knowledge, nor any tooling. Of course with various build tools, the guidelines could hardly cover this :/
Is there any value in standardizing methods (probably using conditionals in the spec) to minimize build-time dependencies? If you have a very core package that needs the whole X stack to build one of its subpackages, maybe conditionalize the build so that you can build without that subpackage and not need X. (autoconf needs emacs? Wow.)
I think currently we have only one or two places where we absolutely require lua for scriptlets. bash is the only one I can think of, because it would otherwise need itself to install. Is there value in using it more often, for more core packages?
I wonder how many packages have additional build-time dependencies solely for running %check. Would it be reasonable to be able to separate these somehow (BuildRequires(check): foo) and to pass up disabling %check through our tooling?
This would be cool, since having rubygems on my mind, the BRs are typically just %check dependencies.
Vít
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:
http://developerblog.redhat.com/2014/12/19/bootstrapping-power8-little-endia...
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.
On a wider scope, I'd agree to gradually minimizing Fedora's 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?
Ralf
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:
http://developerblog.redhat.com/2014/12/19/bootstrapping-power8-little-endia...
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.
On a wider scope, I'd agree to gradually minimizing Fedora's 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. These are not needed for most of packages for scripting languages. Considering the amount of packages which are using Python, Perl, Ruby, Nodejs, Java and name your favourite scripting language here, the gcc & co is mostly useless.
Vít
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:
http://developerblog.redhat.com/2014/12/19/bootstrapping-power8-little-endia...
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 Fedora's 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 "gradually".
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.
Ralf
"VO" == Vít Ondruch vondruch@redhat.com writes:
VO> I agree with these of course. And I'd go one step further and remove VO> also gcc, gcc-c++ and make.
To be honest, I also think it's time to do this. We should have nothing in the buildroot that doesn't absolutely have to be there, and I'm sure it would be easier for ordering complete rebuilds if the dependencies were all completely specified.
And as to religious arguments, I like Perl. I've written probably over a third of a million lines of Perl. And I still think it should be removed from the buildroot, just because I don't like waiting for koji to install unnecessary packages just so I can do a scratch build.
- J<
Dne 22.12.2014 v 19:16 Jason L Tibbitts III napsal(a):
"VO" == Vít Ondruch vondruch@redhat.com writes:
VO> I agree with these of course. And I'd go one step further and remove VO> also gcc, gcc-c++ and make.
To be honest, I also think it's time to do this. We should have nothing in the buildroot that doesn't absolutely have to be there, and I'm sure it would be easier for ordering complete rebuilds if the dependencies were all completely specified.
- J<
So how about Removing gcc, gcc-c++ and make (or something more?) from the exception list as a start? Then after while (lets say F24 timeframe) remove the packages from the minimal build root. In the mean time, rpmlint can be updated to throw an error in case it detects that any of these packages is in use.
Vít
On 12/23/2014 09:54 AM, Vít Ondruch wrote:
So how about Removing gcc, gcc-c++ and make (or something more?) from the exception list as a start? Then after while (lets say F24 timeframe) remove the packages from the minimal build root. In the mean time, rpmlint can be updated to throw an error in case it detects that any of these packages is in use.
+1
Dne 5.1.2015 v 17:35 Miroslav Suchý napsal(a):
On 12/23/2014 09:54 AM, Vít Ondruch wrote:
So how about Removing gcc, gcc-c++ and make (or something more?) from the exception list as a start? Then after while (lets say F24 timeframe) remove the packages from the minimal build root. In the mean time, rpmlint can be updated to throw an error in case it detects that any of these packages is in use.
+1
I opened FPC ticket requesting this change:
https://fedorahosted.org/fpc/ticket/490
Vít
Dne 8.1.2015 v 09:18 Vít Ondruch napsal(a):
Dne 5.1.2015 v 17:35 Miroslav Suchý napsal(a):
On 12/23/2014 09:54 AM, Vít Ondruch wrote:
So how about Removing gcc, gcc-c++ and make (or something more?) from the exception list as a start? Then after while (lets say F24 timeframe) remove the packages from the minimal build root. In the mean time, rpmlint can be updated to throw an error in case it detects that any of these packages is in use.
+1
I opened FPC ticket requesting this change:
https://fedorahosted.org/fpc/ticket/490
Vít
Anybody form FESCo minds to comment on this ticket? Does it need FESCo's attention?
Vít
On Fri, 09 Jan 2015 10:06:55 +0100 Vít Ondruch vondruch@redhat.com wrote:
Dne 8.1.2015 v 09:18 Vít Ondruch napsal(a):
Dne 5.1.2015 v 17:35 Miroslav Suchý napsal(a):
On 12/23/2014 09:54 AM, Vít Ondruch wrote:
So how about Removing gcc, gcc-c++ and make (or something more?) from the exception list as a start? Then after while (lets say F24 timeframe) remove the packages from the minimal build root. In the mean time, rpmlint can be updated to throw an error in case it detects that any of these packages is in use.
+1
I opened FPC ticket requesting this change:
https://fedorahosted.org/fpc/ticket/490
Vít
Anybody form FESCo minds to comment on this ticket? Does it need FESCo's attention?
I'm just one FESCo member, not speaking for everyone, but IMHO yes.
It's a change that would affect a large swath of packages.
So, I would say it needs some discussion on devel list, then run by FESCo and announcements, etc. Likely also a f22 Change to have a place to point people who miss the discussions.
I'm not against it, but it seems like a fair bit of work...
kevin
On Mon, 22 Dec 2014, Ralf Corsepius wrote:
So, why not remove all scripted languages from buildroots and require them to be explicitly BR:'d and R:'ed?
explicit 'R's seem to always end up with needless E:VR or a subset of the same; having a detection script is less likely to pollute the runtime with false or falesly versioned R's than manual mungeing
BR's are harder, but I always cast a suspicious eye on versioned BR;s in scripting languages, as they seem to pull in 'later' and unrelated modules far beyond reason
The trend is for 'thinner' requirements with the emergence of docker, and other cloud'y images; I'd move that way rather than adding yet more cruft inside a spec file. Minimal BR's usually yield smaller R's and smaller packages
-- Russ herrold
On 12/22/2014 12:26 PM, Petr Šabata wrote:
On Sat, Dec 20, 2014 at 11:55:36AM -0600, Jason L Tibbitts III wrote:
I wonder how many packages have additional build-time dependencies solely for running %check.
Plenty. Pretty much every perl package we have, for example.
It actually is the norm to have additional build-time-deps just to run testsuites (aka. %check). It's only the fact many packages don't ship evolved testsuites, which shadows and hides this.
If we'd want to change something about this, rpm would likely have to modified - I don't think this would be advisable.
Ralf
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> If we'd want to change something about this, rpm would likely have RC> to modified - I don't think this would be advisable.
I was kind of hoping Panu or some other RPM dev would notice the thread and give a hint as to how painful it might be. I'm not entirely sure how to get their attention otherwise.
- J<
Dne 22.12.2014 v 19:18 Jason L Tibbitts III napsal(a):
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> If we'd want to change something about this, rpm would likely have RC> to modified - I don't think this would be advisable.
I was kind of hoping Panu or some other RPM dev would notice the thread and give a hint as to how painful it might be. I'm not entirely sure how to get their attention otherwise.
I'm adding jzeleny into CC. Hopefully he will delegate this question to someone from RPM team, who could elaborate.
Vít
On 12/20/2014 06:55 PM, Jason L Tibbitts III wrote:
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.
I have plan for upcoming weeks to implement this: http://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping in mock and mockchain.
packaging@lists.fedoraproject.org
-
Jason L Tibbitts III -
Kevin Fenzi -
Miroslav Suchý -
Petr Šabata -
R P Herrold -
Ralf Corsepius -
Vít Ondruch