[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Dependency loops considered harmful?

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 gmail com>:
>>>> 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.


Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]