> On Tue 13 Jan 2015 01:35:26 AM CET Kevin Kofler wrote:
> > I actually think that cmake should be added to the minimal build root,
> > instead of removing stuff. Almost all the packages I work on BuildRequire
> > cmake (which also implies that they need make to build, and gcc-c++ is the
> > typical implementation language).
>
> Yes good idea. I worked on Java packages. Let's put Maven in minimal
> buildroot. I am sure everyone will enjoy it.
And, you know, why not, exactly? It’s not like the minimal buildroot is a cloud image where every megabyte is multiplied by hundreds of thousands of users and costs money. Rather, the inevitable series of dozens of (yum install $library-devel) every developer does after installing a new OS is much more of a hassle than a few hundred megabytes of space used by default.
Yes, let’s agree (hah!) on good, stable, well-designed programming languages and libraries, and then install them by default in both the Workstation default install and the default build root.¹
> Seriously though what's a problem with listing your package's real build
> requires?
Life is too short to spend time micromanaging things that don’t actually matter for improving utility of the resulting applications to users. Micromanaging the dependencies is not inherent to solving any application use case; it is purely accidental complexity / pointless hassle.
Lidem myšlení—strojům dřinu!²
(Incidentally, this would be much less of a problem if we had a way to add all the needed BuildRequires: automatically, and actually did that. But the mere presence of these BuildRequires: in spec files would still be accidental complexity we are introducing into packaging—or alternatively, if we had a tool to detect this dependency then we wouldn’t need to explicitly list the dependency in the spec file.)
Mirek
¹ Now I am not saying that C/C++/make are that great that they would now warrant being chosen for to the default set but they are so prevalent that if there is any default set it has to include them.
² Let people think and machines toil.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
