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 unnoticed. 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 suffices. 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? -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
