On Thu, 2008-09-04 at 02:43 -0700, Toshio Kuratomi wrote: > >> your app suddenly can't find libFoo.... > >> (Worse is if your working on an app sporadically and have to figure out > >> why it's broken not knowing when it became that way.) Is knowing how to use "yum whatprovides" really too much to ask? A developer who was hit by this would merely need to run "yum whatprovides libFoo.so", then install the necessary package with "yum install libfoo". Since they asked for it by name, it would not be flagged as a dep, and thus be immune from future package culling. And furthermore, a developer using libFoo would have to have libfoo-devel installed. Most likely libfoo-devel is a leaf itself, thus is there because the developer specifically installed it, making it immune from culling. Since -devel packages must depend on the main package, libfoo would remain pinned in the system as long as libfoo-devel is installed. libfoo would never disappear unless the user/developer started deliberately removing -devel packages. If they do such a thing without understanding the potential consequences to their un-packaged applications, they deserve what they get. And that is a problem that has little to do with the proposed auto-culling system. > If I'm developing an app, I'm going to be working on code, not taking > time out to package the app as an rpm. Only after I'm ready to take the > app and put it somewhere for other people to download and use am I going > to start worrying about packaging. Then you accept the consequences of such a development methodology. > >> So if we track this some way, there needs to be a way to disable it. > > > > A developer presumably doesn't use the hypothetical simplified > > application installer. They use something more advanced. Like aptitude. > > > Err.... You've totally lost me here. If we implement this, it needs to > be at a low enough level that anyone installing packages on the system > will be storing the information. This would be ideal, but not strictly necessary. If some tool doesn't know or care about the flag, it should default to "off", meaning "not pulled in as a dep", which would maximally prevent surprises. This is how aptitude works, it stores the "is a dep" flags in its own configuration. Any packages installed outside of aptitude are assumed to be explicitly installed. Yes, the flag should be stored in the RPM database itself, but it is not strictly necessary to implement a proof-of-concept, at say the yum level. Pretty much all our "official" tools are going through yum these days anyway... > That could mean rpm (since rpm is > responsible for taking the package and turning it into files on the > filesystem) or that could mean yum since yum is the one that actually > knows whether a package is being installed due to depsolving or user > request. Doing this at a higher level means that information gets lost > (for instance, if you do this in PackageKit, there won't be any > information about what anaconda chose to install due to chckboxes being > clicked and which things were installed due to dependencies). All the RPM database needs to do is store a single lousy bit of information per package. The "is a dep" flag. Presumably installing packages directly with rpm would not set this flag. Perhaps rpm could provide a command to toggle the flag. RPM itself would not care what the flag means. Giving it meaning happens at the dep solver level. (Aptitude has its own dep solver, which allows it to do the on-the-fly interactive dep-solving that makes it so awesome) > With that said, there needs to be a way for a developer to tell yum not > to prune away leaf packages if they want. An advanced front end, such as aptitude, allows you to manually toggle the "is a dep" flag with a single keystroke. And instantly shows you the effect of doing so. And makes you look at a detailed summary of every transaction before it is performed, giving you ample opportunity to reconsider what you're doing.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
