Dependency loops considered harmful?

[Matthew Woehlke]

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

>> 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.)

>>>> 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.

-- 
Matthew
This message represents the official view of the voices in my head.
   -- Unknown
(found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)