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)
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
