[Bug 226377] Merge Review: rpm

[Robert Scheck]

Hello you two,

hope you enjoyed the weekend so that we can go on without routinely taking
quotes out of context as in the past. I don't want to use names here, the
persons itself know exactly, where I'm talking about.

On Fri, 24 Aug 2007, Axel Thimm wrote:
> Personally I think rpm is really in the second category above, after
> all the operation of the low level package manager, e.g. rpm, is where
> all our packages base upon. So it is a critical system component we
> shouldn't be messing with even if the poiltical cliamte were
> different.

I would like to tell you an example which IMHO matches this scenario and
should hink only very less. Fedora is shipping glibc as standard libc and
it is also shipping dietlibc. Per default glibc is used, but the users can
install dietlibc, compile stuff against dietlibc, they even could rebuild
there whole system against dietlibc, right? But nobody of Fedora would take
care of it, when there are dietlibc specific issues, bug reports or similar
things. AFAIK glibc and dietlibc can be installed in parallel and dietlibc
can be used by the brave ones interested in breaking what they do. So far
so good. And please now replace "glibc" by "rpm.org rpm" and "dietlibc" by
"rpm5.org rpm" and re-read the clause.

If you can't agree with my glibc vs. dietlibc example, dietlibc has to be
removed immediately from Fedora as it violates for the same reasons.

> I think rpm5 in Fedora is dangerous. At the very least it reverses
> the ordering of letters and digits and thus breaks a ton of packaging
> techniques. Any *-1.fc8 -> *.1.1.fc8 upgrade path is busted for
> example.

Can you please immediately stop talking such bullshit? The thing, you are
describing above does not exist in the 4.5 branch of rpm5. Otherwise please
point out things like this e.g. in CVS of rpm5.org.

> What this means is that for rpm5 to technically play nice with rpm it
> needs to be castrated beyond recognition. It would be probably blend
> just as much as dpkg or gentoo build tools.

Why do you want to castrate rpm5? As of now, there is no good reason to do
so. And please read on first (especially the last part of this mail before
replying to it). I'm only interested in facts and not in common blah-foo.

> These technical blockers could be addressed if there were not the
> political issues created by rpm5's developer.

Nice try. Wie man in den Wald schreit, so schallt es heraus. As I don't
know how to translate this phrase best: If you're nice to everybody, they
are nice to you, too. I think this says everything. And I don't want to
talk about the history of the political things. Finally, rpm5 is just even
more than the one special developer you maybe personally dislike or simply
hate.

> Personally I think rpm is really in the second category above, after
> all the operation of the low level package manager, e.g. rpm, is where
> all our packages base upon. So it is a critical system component we
> shouldn't be messing with even if the poiltical cliamte were
> different.

How does low level have an impact, if I don't want to replace rpm.org rpm?
If you think, there's an impact somehow, dietlibc has the same impact to
glibc, as dietlibc (or maybe take uclibc, if you want to think of another
example) is just same low level and system critical. The problem are not
the political issues (if they really exist) itself but the thinking of
individuals of us within the Fedora project and the personal antiphaty to
rpm5 developers is the real problem behind the doors. Think about it...

> (If the political climate *were* different there wouldn't be rpm.org
> and rpm5 coexisting in the first place, so bringing in rpm5 into
> Fedora would be quite a paradoxon ;)

Well Axel...you're only speaking for yourself, not for all of us. But I
don't want to feed the trolls, so lets switch to the technical things as
the politics for normal only rarely produces something usable. IIRC Max
said something, that the technical points matter, right?

On Fri, 24 Aug 2007, Panu Matilainen wrote:
> 1) The internal BDB version differs, IIRC rpm5 uses BDB 4.6 which is
> on-disk incompatible with older versions used by current rpm.org.
> Database format upgrade is done automatically but downgrading is a
> manual, not entirely trivial operation.

Well, rpm5 is able to ship any BDB version (maybe with some exceptions) if
this would be a real blocker. An alternative that was proposed would be to
link rpm.org libraries which inadvertently re-export BDB routines through
ABI because of no loader map (as far as it is known out of the box). And if
looking deeper into, there is maybe another solution for this.

> 2) Even ignoring 1), rpm5 uses so called "tagged indexes" to speed up
> certain operations. Once something has been installed with tagged
> indexes, trying to remove the package without them will segfault due to
> rpmdb internal incompatibility.

This sounds to me that you dislike performance speed-ups *shrug* okay,
without fun: This feature can be reverted easily or IIRC there is a chance
to disable this by a macro. Finally: No real problem.

> 3) There are some other potential rpmdb format differences between the
> two such as file digest implementation.

Digest was parameterized, not only md5 is permitted. Meanwhile only md5 is
everywhere, no other choice is anywhere. So we can remove this point from
the list of possible incompatibilities.

Panu, but you should go and e.g. backport the __db* removal, because this
is a real flaw in rpm.org rpm which many users are complaining about and
which would make some things regarding the possibility to integrate rpm5 as
optional thing into Fedora more easily. I'm loving it (TM) not to be forced
to type "rm -rf /var/lib/rpm*/__db*" from time to time.

Oh and ever thought about the Fedora users using sqlite as rpmdb? This is
already an incompatibility within Fedora which could hurt - as of the rpmdb
format differences. Whenever you're doing something on your own, it's your
private party and your mess, not Fedora's one. And exactly the same applies
when you replace "sqlite" by "rpm5" in this scheme.

At this time, it is a good point to say "thank you" to the rpm5 developers
which also had a look to things that were pointed out until now. To avoid
the unwished names here, just in general and one special guy knows, that I
am talking about him.

> Another issue is that while most of rpm5.org could (can, I think) be
> parallel-installable, the python bindings wont. Or at least, they'd have
> to live in a path where it won't be picked up by the other tools such as
> yum & co. So either there's a direct conflict which is not ok, or the
> parallel-installable rpm5 python bindings are just useless for almost all
> practical purposes.

Why would a direct conflict not okay? There are many packages in Fedora
which can conflict each other. But on the other hand: "What's yum?" Again,
I don't want to replace rpm.org. If you compile one package using dietlibc,
not your whole system uses dietlibc after it. If rpm5 is compatible to your
result of your daily job, what's the problem? Use "yum foo bar" by rpm.org
and do some nice things by using /usr/bin/rpm5 or however I'll call it...

At least: I'm ignoring some politics and personal interferences, that's why
I'm using Fedora and rpm5, I like features in rpm5 which are not in rpm.org
rpm and I still hope, there are many other people, too. Are there further
technical-only related things which could be a real problem? As far as I
understood Max, there should be nothing preventing me from my way.

I would like to see this mostly useless discussion stopped here right now,
come up with real matters, if my review proposal went into. Otherwise we
are only talking about hot air and for normal nothing is eaten such hot as
cooked.

Axel, as we all know, you like to have the last word on the list, I left
you enough points to put them in a mail to fill my personal expectation ;-)


Greetings,
  Robert