Dependency loops considered harmful?

[Toshio Kuratomi]

Matthew Woehlke wrote:
> Toshio Kuratomi wrote:
>> Matthew Woehlke wrote:
>>> Toshio Kuratomi wrote:
>>>> Uhm... you realize that building an rpm every time you want to test a
>>>> change as you develop an app is incredibly clunky?  It really is not
>>>> going to happen.  Really.
>>> I still submit that this itself is a problem that should be worked on...
>>> Why must it be "too clunky"? Why can't we fix it so that expecting
>>> developers to install via rpm, even for incremental builds, is perfectly
>>> reasonable?
>>
>> Here's the workflow:
>> [snip]
> 
> Thanks, but I didn't need an analysis of the current problems. I know
> it's not practical right now, but that was the whole point I was trying
> to make! Here's what I'd like to see:
> 
> 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.

>>> Of course this process probably won't involve going through
>>> a full rpmbuild, just something that tracks the installed files in rpm's
>>> database along with updating the database for dependencies (i.e. it
>>> would replace 'make install' but not 'make all').
>>
>> This is definitely not what rpm is designed to do.
>>
>> You could probably write a script that did it but you'd have to hook it
>> up to all the dependency generating scripts and do minimal parsing of
>> the spec file to get manually specified deps and you'd still have to
>> work out how to do the make install step cleanly.... I don't see much
>> return on investment here but YMMV.
> 
> Yes, you'd probably need to write a spec file, and you might need to
> fiddle with the 'make' step as well to make it more rpmbuild-like. Of
> course, something like this could also be integrated with popular build
> systems (I'd mainly care about cmake).
> 
> For that matter, rpmbuild might just work as-is if allowed to start with
> "dirty" source and build trees; you'd have to set things up carefully,
> but then it would be just a matter of having the source in a particular
> spot (which could be symlinked to get around any inconveniences there)
> and running rpmbuild instead of make. Then the trick is just making it
> work as not-root.
> 
> What I *don't* get it what's so special about rpm generation that people
> seem to think this can't be done. Would it produce an rpm that is
> suitable according to Fedora's packaging guidelines? Of course not! But
> that's not the objective. Yes, there are reasons current rpmbuild works
> the way it does, and I don't think we should change that. I'm just after
> a way to allow "non-canon" rpm's rolled from incremental builds.
> 
> Further, they should NOT be root-owned, they should be installable
> without needing to be root*, and they should stick out like sore thumbs
> if there is a conflict with repo packages (assuming they aren't
> installed "in addition", i.e. in /usr/local).
> 
> (* There should be a way for root to flag a particular such package as
> being allowed to satisfy dependencies for other packages, that would be
> persistent across updates of the package. IOW, I can install qt-copy,
> become root and tell rpm to use qt-copy to satisfy dependencies, and
> then poppler-qt4 without having to install the repo qt4. Now, obviously,
> trying to remove qt-copy will refuse due to poppler-qt4 needing it until
> I use the magic incantation (e.g. '--force --nodeps' or something along
> those lines, which would of course break poppler-qt4, but I was warned
> ;-) )... unless I do it as root, which would just remove poppler-qt4.)
> 
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.  And when you do that, you probably also
want to make sure the per-user installed packages override the
system-wide installs.  And you also have to deal with setuid binaries
and the places that random programming languages expect to load their
libraries from.  It all gets very complex very quickly and starts
looking a lot less Unix-y.

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.

>>>>> 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.
>>>> s/not// to match the behaviour you say aptitude has.
>>> Eh? I would think that 'rpm -Uvh <some-package>' should result in
>>> <some-package> being flagged as a non-candidate-for-culling (unless rpm
>>> is told otherwise). IOW, if I hand-installed some rpm, I don't want it
>>> auto-culled. Maybe there is some miscommunication?
>>>
>> Possibly.  I interpret the "is a dep flag" to mean package Foo was
>> installed as a dep of package Bar.  Therefore, when package Foo is
>> uninstalled, packages that depend on Bar and have "is a dep" set would
>> be uninstalled.
> 
> Right, if those "is a dep" packages aren't needed by anything else (just
> to clarify; I'm sure that's what you meant).
> 
> 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.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080904/4cef2ade/attachment.sig>