Michael Schwendt wrote:
On Thu, 30 Aug 2007 15:08:40 +0200, Stepan Kasal wrote:
Hi,
On Thu, Aug 30, 2007 at 02:55:12PM +0200, Michael Schwendt wrote:
On Thu, 30 Aug 2007 14:10:57 +0200, Stepan Kasal wrote:
I also considered util-linux, when jnovy mentioned that a package
needs "kill" to build properly. But I came to a conclusion that
"kill", "mount", nor any other command from util-linux doesn't have
to be in the minimal buildroot.
arch, flock, getopt, rename are nice to have by default.
well, might be nice, but I'm afraid we need to be more exact.
Could you please find out or estimate, for each of the utils you
mentioned:
- how many upstream tarballs do not build without it?
- if they do not build, is it a transparent error, or
is it a hard-to-debug problem (builds but does not work in
certain special cases, for eample)?
- how many spec files call the utility?
If the number of packages affected is small, and if the broken
packages are easy to discover and fix, we can leave util-linux out.
Hyperbole. If such an enormous effort is needed to justify adding a
core package, it is certainly not worth it. It would require burning
cycles on thousands of tarballs, builds and checker-scripts to see
whether a tarball disables features or self-tests when a tool is
missing.
The "initscripts" package used to require "util-linux". For a package
that is available on the majority of Fedora/RHEL installations, I
don't see any reason to make it a special optional build requirement.
I'd rather add a generated set of buildroot packages to spec files
and save the time.
Actually, we have been using a rebuild script here that actually does
some of those tests, though it's by far not 100% correct as it basically
only checks after a rebuild if
- The package built at all. If not, keeps the logfile to see where it
went wrong to figure out what was missing
- The build worked but the new requirements are different from the
"original" build.
The 2nd point obviously only covers stuff that generates requirements,
but in most cases this will happen (e.g. if you build some package that
checks for a lib and the devel package for that lib isn't installed it
will disable the feature then your final package will not have the
requirement on that said lib anymore, so an automatically detectable
change).
I think Karsten Hopp sent around a list every once in a while with the
results of those rebuilds. We're currently in the process of cleaning up
and documenting those rebuilds scripts properly (ugly hacks FTW ;) ) and
release them in the near future (some public repository). Keep in mind
though that a full rebuild of Fedora even on PHAT machines takes an
awful lot of time. We're using a big Intel 4 CPU dual core HT machine
(so virtually 16 CPUS) with loads of memory and even on that box it
takes several days to complete. Also disk storage needs to be quite
large as we need to keep a whole tree mirrored on disk (source and
binaries for comparisons) together with up to 20 build processes running
at the same time and logfiles and final binary rpms being stored. Ofc
you can do single rebuilds or partial trees with the scripts as well. ;)
Read ya, Phil
--
Philipp Knirsch | Tel.: +49-711-96437-470
Team Lead Core Services | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <pknirsch@xxxxxxxxxx>
Hauptstaetterstr. 58 | Web: http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd: You're only jealous cos the little penguins are talking to me.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
