[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: util-linux missing from build root

On Thu, 30 Aug 2007 04:35:43 +0200, Ralf Corsepius wrote:

> > Then substitute the examples with glibc, libstdc++, binutils, cpp,
> > file, grep, mktemp, util-linux, ... you get the idea.
> The key to get this usable would be to use a _list of applications and
> libraries_ and keep this _list constant_. Not a list of packages as it
> is being done now.

That would be a next [harder] level and also a key to verifying
periodically that the low-level contents of the minimal buildroot
packages stay the same. That is, that no files get removed or renamed

A list of package names is of limited use, sure. But it is better than
no such list.

We've defined the contents of our minimal buildroot by means of
traversing the dependencies of a smaller, essential root-set of
package names and checking whether the full set of dependencies

That's why "python", "grep" and "file" have been an implicit BR in the
fully expanded list, for example, while we've had to add "perl" and
"unzip" to the root-list explicitly. Historically, a few packages have
been added to the primary list explicitly as a safety measure, as not
to rely on dependencies in those cases and to ensure they are really
pulled in. The same could have been done with further packages and,
apparently, is necessary *now*.

The full set of packages has not become the primary list because it is
the result of recursion and as a side-effect contains several
"disturbing" packages, which are not as plausible as many of the
others on the list. You could only get rid of them by excluding them
explicitly -- more work for those who've maintained the list so far.

 From the perspective of Joe Packager, if you need a program/file, you
hunt it down, "rpm -qf" or "repoquery --whatprovides" it, and add the
found package name as a BR. Yes, you could be pedantic and add the
full path of the needed file instead, but that would break if a
program were moved around in $PATH. Also, who would verify that a huge
configure script strictly requires /bin/foo instead of $(which foo)
for several dozens of different tools?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]