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
