Re: Dependency loops considered harmful?

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

 



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!

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux