Who maintains RPM? (2011 edition) [LWN.net]

Who maintains RPM? (2011 edition)

Posted May 7, 2011 0:21 UTC (Sat) by proyvind (guest, #74683) [Link]

upstream alienation? In what way? I'm not sure what you're referring to..?

And Dmitry Komissarov has nothing to do with our choice of rpm5, nor do I get what stupid management decission you're referring to either..

Who maintains RPM? (2011 edition)

Posted May 7, 2011 11:10 UTC (Sat) by gvy (guest, #11981) [Link]

> I'm not sure what you're referring to..?
rpm5.org rejection of hasty patches with subsequent access mods.

> Dmitry Komissarov has nothing to do with our choice of rpm5
Glad to hear that, actually. (and read up a bit on developer's discussion as well)

> what stupid management decission you're referring to either..
I've specifically noted "(from my judgment)" *asserting* that "feature pressure" was done downwards on developers, not a decision made by technically savvy. If it were rpm5 (or systemd, or any other part of the whole bunch) _alone_, I'd be less inclined to assert so.

During Russian school project, Dmitry has achieved something of a record on mismanagement -- managing to bring a successfully piloted project (by ALT Linux) to a full-scale grave. I spoke to him many times but he seems very much like a self assured moron unable to acknowledge his shortcomings, unfortunately.

I'd also like to warn that NGI fund seems to have lost in Russian government gamble, so there might be some sense to have a plan B for those working at Mandriva looking at how Sickola Narkozy regards free software, both national and in general.

Who maintains RPM? (2011 edition)

Posted May 7, 2011 13:13 UTC (Sat) by proyvind (guest, #74683) [Link]

rejection of hasty patches? Hm, I guess you must be referring to mine and Jeff's "artistic differences" and timeframe... ;)

Basically a lot of required changes and new features was had to be rushed into rpm5 cvs, often under a #ifdef RPM_VENDOR_MANDRIVA for us to get where we wanted in time for our upcoming release, this is much due to lack of better revision control such as ie. git (which we're likely to move to soon) and the need for having changes mainttained upstream rather than locally patched, so for these to be both reviewed and also for Jeff to do continous integration with buildbots running cooker and building latest cvs code. Jeff's complaints was more of a result of me spending more time to get things done and code committed way later than was expected, thus misinterpreted, nothing whatsoever related to any feuds, big disagreements or anything. Our relation has always been good, so to others viewing it from the outside, the impression might be entirely messed up, not knowing much about what's not posted on the public list...

For the feature pressure, this has simply come from the community, and something I think is a great thing as we seem to be pulling it off nicely. :)
RPM5 is something I've been involved with over a few years now and has been trying to push for a long time, with new management finally taking interest in opinions and ideas of mine, in contrast to old one. Systemd is Andrey Borzenkov to be creditted, another community member which has done the major work and efforts related to systemd.

All in all, the experience with Dmitry within Mandriva is overwhelmingly positive with a quite favorable view by most, given our bad history with awful management in the past, I guess the bar wasn't set really high, but so far the level of sanity seen is far above average, something which has been more motivating than much else in a long, long time, leaving a very good atmosphere and environment within mandriva and community now, which a year ago was certainly not the case..

For Dmitry in relation to ALT & Russia, I can't speak, nor know much about it beyond some comments on why not going with ALT, which I'd rather not find appropriate disclosing in public. I can only say that you have my sympathies for any possible mismanagement or foul play that might've taken place with regards to your project...

I was always hoping for a closer collaboration with ALT Linux, and also hoping for increasing their involvement in rpm5.org and on sharing efforts on distribution, giving all the synergies shared and and their common history dating back to Russian Linux-Mandrake, and I still very much hope so for this to happen regardless of who wins the bid with the Russian government or not (hey, it might not be either of us, it could just as well be ASP Linux..;).

But rest assured, please do not interpret greater technical changes and activity wrt. cooker development as a direct consequence of Komissarov's involvement, it's rather more a result of greater influence and more development done by Conectiva now, which is a very good thing and quite promising in the long run.

I'm hoping this is not the last we speak, with the next occation being under better circumstances and of mutual benefits and interest. :)

--
Regards,
Per Øyvind

Who maintains RPM? (2011 edition)

Posted May 7, 2011 0:37 UTC (Sat) by Ansus (guest, #74724) [Link]

> Two of its primary maintainers are also rpm5.org committers.

The list of committers also includes people from CentOS and Fedora. Do you claim that they also want to switch to RPM5? :-)

Actually people from Alt Linux expressed that they do not have any plans of migrating to RPM5 and discribed this article as disinformation as I pointed it to them.

Who maintains RPM? (2011 edition)

Posted May 7, 2011 0:51 UTC (Sat) by Ansus (guest, #74724) [Link]

> rpm5 also seems like an attempt at macro set unification, which isn't likely with RH controlled branch FWIW.

I am a maintainer and packager in openSUSE and I would say that the macro set in other modern distributions (Fedora, Mandriva) is rather compatible with ours. The only macros with which we have problems are icon update ones and of course with the names of the devel packages.

> But rpm5 also seems like an attempt at macro set unification, which isn't likely with RH controlled branch FWIW.

RPM5 is a way to break package compatibility between distributions first of all.

Anyway, I am sure that any migration to RPM5 cannot be justified with such behavior of the upstream. I read the Jeff's posts in the mailing list, his accusations of everybody around of being mentally ill etc and I would say that anybody who still wants to migrate to RPM5 should blame themselves for their stupidity.

Who maintains RPM? (2011 edition)

Posted May 7, 2011 3:23 UTC (Sat) by proyvind (guest, #74683) [Link]

Yeah, you might be a packager, but I bet you're not a rpm developer, now are you..?

The macros and compatibility between suse, fedora and mandriva as currently is and has historically been isn't worth shit.

The move to rpm5 is rather to standardize packaging around upstream, and not by trying to solve it with awkward macros to get half-assed adopted somewhere here and there, but never remotely sufficient to be of much relevance.
And just by stating that you're a package maintainer in opensuse doesn't really give you that much credibility to have insight on matters beyond suse packaging, much less rpm internals itself, and by claiming that macro sets in other modern distributions is rather compatible with yours, you're just revealing how way off you really are..
If you think more consistent macros is the solutions to everything, good for you, but what we want to achieve, and what I'm working on related to rpm5 is actually on implementing proper functionality within rpm itself, to be automized, externalized from spec files, and reduce the huge crap pile of macros and feeble attempts of achieving compatibility with %if foo blablbla %endif.
JPackage is a brilliant example of how miserably failures such attempts usually are, we'd rather work on making such project superfluous...
But go on, your macros will probably lead you to the magic leprecon, taking you to the gold at the end of the rainbow..
But in the real world, there's a need for cleaner, simpler, and well-designed means to achieve any sensible form of compatibility..

If you read our mailing lists, then you should also notice that Jeff's responses are well warranted, even though a bit hot-headed and misinterpreting people occationally, something which you cannot blame him for considering people's behaviour and attitude..

Jeff has been the person over the last month who's actually been the most active and helpful on cooker, and also given us a huge boost in discussing new ideas and related r&d, while being frequently trashed by the same group of people with their own agenda.
You can find these same people having been especially active dating back to september since the mageia announcement, trolling and generally generating tension on the list before Jeff turned up as well..

Who maintains RPM? (2011 edition)

Posted May 7, 2011 13:48 UTC (Sat) by Ansus (guest, #74724) [Link]

> reduce the huge crap pile of macros and feeble attempts of achieving compatibility with %if foo blablbla %endif.

I have ported hundreds of packages from other RPM distros and as I can say, the only places where you have to place %if...%endif most often are the BuildRequires tags due to different package names and the update-desktop-files machinery.

(offtopic) from .desktop accounting department

Posted May 9, 2011 12:42 UTC (Mon) by gvy (guest, #11981) [Link]

> [...] and the update-desktop-files machinery.
...which is best done by a posttrans trigger IMO&X.

Who maintains RPM? (2011 edition)

Posted May 7, 2011 13:50 UTC (Sat) by Ansus (guest, #74724) [Link]

> If you read our mailing lists, then you should also notice that Jeff's responses are well warranted

From what I saw he attacked completely uninvolved people for even friendly questions.

Who maintains RPM? (2011 edition)

Posted May 7, 2011 13:55 UTC (Sat) by Ansus (guest, #74724) [Link]

> The move to rpm5 is rather to standardize packaging

In fact it will only split package format among distributions removing any hope of reconciliation. Or do you hope that Fedora will switch to RPM5 also? Speaking for openSUSE, it values compatibility with Fedora and will not switch either.

What even worse is that RPM5 breaks not only spec files compatibility, but also makes binary formats incompatible.