Nicolas Mailhot wrote: > Le jeudi 04 septembre 2008 à 09:31 -0700, Toshio Kuratomi a écrit : >> Thomas Moschny wrote: >>> 2008/9/4 Toshio Kuratomi <a.badger@xxxxxxxxx>: >>>> With that said, there needs to be a way for a developer to tell yum not >>>> to prune away leaf packages if they want. >>> % yum install libFoo >>> >>> this might look like a noop, because libFoo is already installed, but >>> it would switch the bit for libFoo from 'installed-as-dependency' to >>> 'first-class-installed'. >>> >> That's a good point. >> >> I'd much rather have a switch to turn the feature on or off per machine >> than to have to remember this per library, though. Apps can have a >> myriad of dependencies. Should the developer have to do sudo yum >> install libFoo for every one of these? Everytime he grows a new >> dependency? > > Quite frankly the argument that the developper could not write a spec > file was already poor (because specs are a piece of cake next to > makefiles and autofoo), I disagree on several points: * If it was really so easy all upstreams would ship with a debian control script or a spec file or gentoo ebuild * I'm sure you've taken a look at the state of upstream's makefiles and autofoo. If they can get that wrong, then getting spec files horribly wrong is only one frustrating step more. * Not every set of build scripts is as hard to create as Makefile/autofoo. Some of them are very easy to setup compared to spec files. Even worse, some of these easy build script systems are inflexible which makes packaging harder. Some developers are good with build scripts. These developers would probably also make excellent packagers. Other developers want to stick strictly with the code they're building their app with. Those people are going to be unhappy enough creating Makefiles, let alone spec files. > but the argument he can not care about the deps > his app uses is ridiculous (both from a technical and legal POW). > I'm not talking about caring about the deps. I'm talking about record keeping for the deps. Sure I know that the app I'm developing requires Foo, Bar, Baz, and Brigit but I don't know which of those is going to disappear in the next round of leaf node pruning. Also, what happens when I start working collaboratively on a project? For instance I shift departments at my University and start working on a weather visualization app. I checkout the source from the department revision control and lo, everything works because I presently have all of the libraries installed. I start hacking away on the rendering portion of the app. I also add and remove application software from my system using the friendly and intuitive PackageKit interface. One day, auto-prune runs and removes a networking library since no presently installed package requires it. Unfortunately, the program requires that in order to run. Suddenly the app stops working for some reason I do not understand due to some segment of code I've never touched. > Please don't take it bad, but developping is more than copying snippets > of code, and a developper that can not care about his software > environment is not worth the name. But is such a developer worth less of our time than any other end-user who does not care about their environment and just wants things to work? I'd argue that having an app work one day and suddenly stop working the next is something we should *not* be striving to achieve even if said app is not packaged. It leads to the perception that our distribution is unreliable and breaks easily. This is an extension of the argument that we should not be upgrading library major versions in a released Fedora due to breakage in software outside our control. Now this is something of a UI issue -- I'm against pruning like this automatically with out a switch to turn it off. But auto pruning with an opt-out would be okay. Having to explicitly touch each library just strikes me as bad UI and a support nightmare. -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
