Dependency loops considered harmful?

[Callum Lerwick]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080904/98ceb799/attachment.bin