On Mon, 2008-09-15 at 13:02 -0400, Behdad Esfahbod wrote:
I'm sure it is a very very complex problem. I also hear that a
lot of these
problems are caused by RPM having to retain a lot of baggage for the name of
compatibility. Hence my conclusion.
have you talked to the rpm maintainers? Also - compatibility is
important, not just to people working on longer-term oses like
rhel/centos/sled but also to fedora package maintainers - remember a lot
of the fedora maintainers also work on epel.
The question is: if one could throw RPM away and design a new one,
could one
do significantly better? From what I hear I think the answer might be yes.
What does it mean to Fedora: we need to kick RPM in the butt to catch up with
competition.
Have you tracked the changes that have been going on currently or do you
consider anything other than 'throwing it all away' not rapid enough
movement? I think you underestimate the sheer volume of code that needs
to be protected/verified and reimplemented if we were to just 'throw it
all away'.
Lets look back at the problem at hand: we all agree that
custom-installed
glob-matched post-transaction triggers are useful things. I think I can also
say that we agree that it should be in the lowest-level package management
system. What has been up to debate so far is whether that lowest-level is
RPM, or that RPM is a lost case and yum is considered the lowest-level. The
answer to that one does not matter. A few data points that put this
discussion in perspective however:
- Michael K Johnson, the very first Fedora Project leader, thought he can
invent a better RPM, left Red Hat, and built Conary. It does use Python
indeed, and it does support glob-matched scripts.
The migration path to conary for fedora is measured in years - not to
mention breaking track considerably with everything that came before us
and the projects forked from us. And, of course, we've just swapped our
known bugs for a whole new set of unknown bugs. It'll be fun to come
back a year after a migration to conary to find a whole different set of
complaints. Hey, Maybe we'll be encouraged to throw it all away, again.
That'd be amusing.
- First Mandriva and then SuSE felt they needed to heavily customize RPM and
went down that road. I wonder how longer we need to wait to reach for the
same conclusion.
Mandriva and SuSE are working with
rpm.org and collaborating to make rpm
better. They did customize things and we're all progressing on a common
tree.
- Kristian Høgsberg built razor which can solve deps in fraction of a second
where yum simply takes way too long. Is anyone in the RPM camp impressed?
No. They just don't think it's possible to do with RPM.
Kristian built something which solves some dependencies. Mostly he wrote
a mmap'd repometadata format.
- RPM already supports %posttrans scripts which are a huge
improvement over
%post, but when I desperately needed them to refresh fontconfig caches upon
upgrade (using %post the old package is still installed when the script is
run; ouch!), but was told to not use %posttrans as it's broken and eats
babies. I'm not sure if that's accurate, but that was the recommendation I
got from very core Fedora developers. This is the kind of limitation RPM
imposes right now.
People use posttrans now - the issue is that posttrans scripts often
make some intriguing assumptions about what you're running on and how
you're being installed. Ditto with pretrans. And posttrans doesn't play
nicely with the rpmdb being accessed/modified right now, either.
Now I understand that using RPM is one of Fedora's biggest assets
("industry
standard" blah blah), so I'm not suggesting that we should move to something
significantly different. Just to acknowledge that there is a problem here,
identify solutions, and fix them.
Have you interacted, at all, with
rpm.org - Panu, Florian, Jindrich
about what they're working on? Maybe reviewed the slides from brno's
fudcon? I think they're posted somewhere publicly. Checked out the git
changelog for rpm.org? Looked at the rpm feature proposals for fedora?
Simply put, Fedora-devel is not the best place for learning about rpm
development. rpm-maint(a)lists.rpm.org is a better place. Look at the rpm
wiki, too:
http://wiki.rpm.org/DevPriorities
If you want to talk about rpm issues that need work, or better yet, if
you want to work on them - come to the rpm-maint list. I can think of
one or two items which I'm sure the rpm devs would love some additional
thoughts on.
File fingerprinting comes to mind as non-trivial and excruciating all at
the same time. And, of course, eminently necessary for putting down
files.
-sv