On Tue, 21 Aug 2007 12:25:18 -0600, Bob Proulx wrote: > Leland Ray wrote: >> One thing that would make it easier is to make >> requires more testable. It would be useful to have a >> flag somewhere that suggests to the installation >> method to move the package as close to the front of >> installation order as possible. > > The problem is what do you do when there are multiple packages hinting > to be "as early as possible"? What should the ordering be there? I > don't think imprecise hinting is the right way to go. Better to have > the actual requirements and then be able to sort based upon those. One simple fix is to have "knots" and "bows". Each loop of a bow is a topological sort; each knot is an inflection point that cordons off one tsort from another. So the OS would go into bow 0, and most of the time, all the other RPM's would go into bow 1. Or you could use them bows like BASIC line numbers - starting with the OS in bow 1000, allowing room for things to come in front and behind. Then as you compute your tsorts, you just catenate them together in bow order to get your ordered list of rpm's to install. >> Another testing problem is that when an install fails to find a >> requirement, whether that error halts installation depends on the >> installer. So anaconda will permit installation of components where not >> all requirements are present, but other installation methods will not. > > I think this is because of an attempt to work around circular > dependencies. I really wish circular dependencies were simply > disallowed. It would solve many problems. One thing that might help is if installers had an "install in random order (within tsort constraints). >> This is going to seem anathema to many, but because I don't have >> control over third party packaging, I'd like to be able to add requires >> to a package without rebuilding it. > > It is mostly possible to create a new rpm based upon an existing rpm > simply by repackaging the binary rpm and without recompiling. There are > some issues trying to do this in the general case but most particular > examples can be recreated. I've seen a program that allows you to edit binary RPM's, but it's copyrighted with a restrictive license at this time. >> My dream is to be able to edit requires-additional.xml in a yum >> repository, and have anaconda, if in a kickstart, or yum, or any other >> package, honor the extra requires as if they were part of the rpm. >> >> Hmmm, perhaps I should wish for this on the yum list. > > It would be more palatable if that fed directly into a bug database such > that whenever it was used it was clearly indicated as a workaround for > bugs in the packaging. I would fear that something like this would > become accepted as a normal way to do things and not as an exceptional > condition to work around bugs. As long as it's a pain in the rear (and IMO, if it doesn't "just work", it is a pain), I think people will avoid it. But adding an XML file with additional requires dependencies to an installer, probably wouldn't be any easier than modifying rpm (the program that installs rpm packages's) to allow adding and removing requires dependencies. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
