Dependency loops considered harmful?

Matthew Woehlke mw_triad at users.sourceforge.net
Fri Sep 5 17:12:43 UTC 2008


Toshio Kuratomi wrote:
> Matthew Woehlke wrote:
>> Current workflow:
>> svn up
>> make
>> make install
>> some-app
>>
>> Proposed workflow:
>> svn up
>> make
>> rpm-dev-install .
>> some-app
>>
>> See how painless that was? And now, rather than 'make install' littering
>> my drive with untracked files, the helper:
>> - rolled an incremental RPM
>> - updated the existing package
>>   - ...which removed any old files no longer there
>>   - ...and added/updated any modified files
>> - updated the rpm database to note that some-app is now installed (if it
>> wasn't)
>>   - ...which also means that if some-app uses libfoo-devel, rpm now
>> knows this and won't remove libfoo-devel until I remove some-app
>
> The thing is you missed that in my current workflow there is no make
> install.  So the issues you have with it dirtying up the drive don't
> exist and all the work (or simply waiting for a package and install step
> to finish) between the make step and invocation of some-app are extra
> overhead.

Well, then, see my reply to Patrice, here: 
http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/91312

I'm not trying to solve the 'install-less' workflow; the benefit from 
that is IMO considerably less than the workflow *I* have, which I 
illustrated above. (In fact, the only benefit at that point is 
dependency marking. File tracking is irrelevant, and if you haven't 
installed, you aren't providing anything, so you have only one of the 
three benefits to rpm installs.)

Specifically, I'm looking at development on interconnected packages 
where the bottom layers /must/ be trunk, and must be /installed/, in 
order to build the upper layers. IOW, running from the build dir would 
work for the endpoint applications, but /not/ the libraries they depend 
on. (Besides that I use KDE4 trunk for my daily desktop ;-), and am also 
building it as a user other than my logon user.)

>> [snip my big long dissertation]
> This is getting really far from what rpm does.  To do this without root
> access, you really need rpm to be able to merge the system rpm database
> with a per-user rpm database. 

True, though what I was getting at was that the user database would be 
known only to the user, except as set up by root. So... hmm, yeah, I 
guess root would be allowed to break user rpm's (i.e. by removing 
dependencies), and I guess the root db /would/ need to know about user 
db's just so it can say 'user A has rpm B that depends on C, so better 
not auto-cull that'. And I guess that means a user can break things if 
they're providing a dependency, but then, if you're worried about that, 
you shouldn't have added a user db for dependency resolution.

Fragile? Sure, but less so than not having any tracking at all.

> And when you do that, you probably also
> want to make sure the per-user installed packages override the
> system-wide installs. 

...which is already the case. I don't think there's anything special 
that needs to happen here; the user is responsible for setting PATH, 
etc, to use userland packages.

> And you also have to deal with setuid binaries
> and the places that random programming languages expect to load their
> libraries from.

Nope. Those things don't work *now* w/o 'sudo make install', so they 
shouldn't be expected to work under any newfangled rpm system either.

Currently I install everything into (e.g.) /usr/local/myuser, which is 
of course writable by the user I'm building as. By doing so, I take 
responsibility for making my packages work when installed here in the 
current workflow. Bringing rpm into it wouldn't change that. Bringing 
rpm in would:

- track the files, so update and remove work cleanly
- track the 'provides' so yum doesn't try to install repo versions of 
the package
- track the dependencies so they aren't gratuitously uninstalled

Yes, the second point is fragile, but I don't think making 
user-installed rpms as robust as root-installed rpms is a desirable 
goal, nor as you have noted, is it realistic. They should be on par with 
user-'make install'd software plus db forging, just without the 
fragility of forging the rpm db.

> Certain aspects of what you want could be done (although they seem very
> out of line with rpm's goals so they'd have to be a separate program)
> but other aspects will need an entirely different conceptual framework.
>  If you're interested, work on it, but it's not something that's going
> to be useful for Fedora without some paring down of the new features or
> a lot of other work.

At the moment at least, I don't have time, but it's certainly something 
I'll keep in mind. From your comments, though, I wonder if you're trying 
to add features to what I have in mind, so it's maybe not as bad as 
you're thinking :-).

>> What I don't get: Callum said that "rpm -i blah.rpm" would mark "blah"
>> as a non-dep, i.e. would not be auto-culled. As I understand, you said
>> that it *would* mark it for auto-culling. It seems to me that the former
>> behavior is preferable; anything I install by hand should be
>> non-auto-culled unless I say otherwise, not the other way around.
>
> You're right.  I've read that wrong several times now.  Thanks for
> correcting me.

Ok, then it seems we all agree on what's sensible behavior :-). Thanks 
for putting up with me getting that cleared up.

-- 
Matthew
On the internet, no one knows you're a cat...
   ...until you meow.
MEOW!




More information about the fedora-devel-list mailing list