Callum Lerwick wrote: > 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. > Both of these answered in other messages: yum install PACKAGE specifically to prevent this is badUI: https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00245.html Why -devel is not enough:: https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00235.html >> 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. > Uhm... you realize that building an rpm every time you want to test a change as you develop an app is incredibly clunky? It really is not going to happen. Really. >>>> 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... > This would work. >> 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. s/not// to match the behaviour you say aptitude has. > 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. > So -- I don't have anything against there being this interface. I just want to see a simple config change that can turn dep removal (not tracking, just removal) off. Developers can be good at coding and awful at system administration just like any other end-user. We shouldn't make them understand package deps and why different packages they need disappear out from under them when they remove an application package any more than we should go back to the time before depsolvers and make office workers understand package deps and why they need to install different packages in order to get openoffice to run. Why do I think a simple config change is the way to go? Because of the miscommunication factor: dev: Why'd Fedora uninstall python-foo when I removed gnome-foo? python-foo works fine without gnome-foo! fedora-sa: That's a new feature of F-10. dev: But I totally needed python-foo for the Uber-Duber-Mega-Foo we're building! fedora-sa: You can work around it by doing a yum install python-foo dev: And yum won't remove it again? fedora-sa: Right [days pass] dev: Fuck! Fedora uninstalled python-bar when I removed gnome-bar! fedora-sa: Did you yum install python-bar? dev: I thought you said yum wouldn't do this anymore! fedora-sa: I did? fedora-sa: Wait, I think that was for another package. dev: What's the difference? I just don't want yum to keep thinking it's smarter than me! fedora-sa: Well, you just have to yum install all the deps that your program has. dev: wtf You're kidding. fedora-sa: no. You should have all the deps, though. I mean, what are you going to tell people when the install it? [weeks pass] dev: yum did it again fedora-sa: What? dev: I just spent three hours figuring out why Uber-Duber-Mega-Foo started throwing exceptions when we try to save files on some of our Fedora boxes. dev: It turns out that code had a dependency on a module that yum automatically removed. fedora-sa: I thought I told you to install all those modules explicitly. dev: That's what I did. dev: But this dep was added by Greg after that. dev: It seems like this problem just refuses to go away. [dev and fedora-sa assume a passive aggressive stance towards each other, continuing to think the other is an idiot.] Now, here's the alternative: dev: Why'd Fedora uninstall python-foo when I removed gnome-foo? python-foo works fine without gnome-foo! fedora-sa: That's a new feature of F-10. dev: But I totally needed python-foo for the Uber-Duber-Mega-Foo we're building! fedora-sa: If you edit /etc/yum.conf fedora-sa: and add the line recursive-remove=no fedora-sa: that will turn off the feature dev: Cool. fedora-sa: And you'll have to yum install python-foo to get this particular library back, of course. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
