Dependency loops considered harmful?

Matthew Woehlke mw_triad at users.sourceforge.net
Thu Sep 4 22:05:01 UTC 2008


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

>>> That could mean rpm (since rpm is
>>> responsible for taking the package and turning it into files on the
>>> filesystem) or that could mean yum since yum is the one that actually
>>> knows whether a package is being installed due to depsolving or user
>>> request.  Doing this at a higher level means that information gets lost
>>> (for instance, if you do this in PackageKit, there won't be any
>>> information about what anaconda chose to install due to chckboxes being
>>> clicked and which things were installed due to dependencies).
>> 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?

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




More information about the fedora-devel-list mailing list