Compatibility and freshrpms

When you use Fedora Core you certainly will come to the point where someone talks about 3rd party repositories and compatibility issues. The background is that there are additional repositories for Fedora which provide a lot of additional software which is not part of Fedora. So far so god, but the story hasn’t ended yet: there are different repositories, and some of them are not compatible with others, and some of them replace packages of Fedora which you probably don’t want to be replaced.

For me one of the most interesting repositories is the one of Matthias Saou, freshrpms.net. It provides a lot of so called “nonfree” packages which cannot be part of Fedora because Fedora does not allow nonfree-licensed packages. Matthias is also one of the top ten packagers for Fedora Extra so he is someone who contributes pretty much to a third party repositorie and is pretty deep in the Fedora packaging stuff itself.

Out of this reasons I decided to ask him some questions about freshrpms, livna, rpmforge and Fedora at all – fortunatelly he answered very quick and detailed, thank you very much :)

Here is his answer together with the quoted parts of my e-mail:

Hi,

These are indeed perfectly valid question I get from time to time :-)

Roland Wolters wrote :

> Hej,
>
> I think you get this question quite often, but I didn’t
> find anything about FC5 so far, so I want you to ask
> some questions about FC5, extras, livna, forge and
> freshrpms.net. I will blog about your answer (if you
> find time to write one), and if you agree we can
> post this to other news to clarify. Here the questions:
>
> Since you and livna.org are packaging some
> packages at the same time:
> libdvdcss, gstreamer plugins, ipw-firmware,
> etc. Why is that happening? That’s doubling of effort,
> wastes energy, and can cause compatibility problems,
> which is bad, because both parties also have
> packages which are not in the other repository (you
> have cinelerra, livna has kernel modules, etc.).

The reason for this one is historical, from the fedora.us days. When fedora.us (Extra’s ancestor) started, Warren wanted to regroup a community effort to package additional programs for Red Hat Linux. To make the story short, I was interested in joining, followed the initial discussions, but didn’t like many little details and finally didn’t join the effort. Those details included things like submitting new packages through bugzilla (which is what Extras inherited, *sigh*) or forcing _really_ stupid things like adding a mandatory zero epoch to all packages. Since at that point fedora.us and freshrpms.net had many duplicates, and that Warren was concerned about packages not legally usable or distributable in the USA, rpm.livna.org was born. The silly part here is that many packages were re-written from scratch by Anvil (Damien Nadé) instead of taking the freshrpms.net ones as a base. That is duplicating effort. Oh, I wasn’t aware of its launch until is was all ready either.

At that point, you had freshrpms.net on one side, and fedora.us+rpm.livna.org on the other “competing”. Note that freshrpms.net has always been “packages that you don’t find in the base distribution”, which means that now it contains packages that aren’t in Core+Extras, so it only “competes” with rpm.livna.org.

About rpm.livna.org : It’s supposedly a community effort, but just the name already contains a single person (livna = Anvil backwards), and Anvil had never contacted me regarding any kind of collaboration until early last year… and as a packager, I don’t like his way of interacting with the community : He disappears for long whiles now and then, doesn’t participate in the Fedora Core development, very little in Extras (often unresponsive and orphaned many of his packages recently)… I wouldn’t
really like switching from freshrpms.net, which has acquired a solid reputation, works really well for users and doesn’t give a (false?) impression of community-driven project, to rpm.livna.org…

> Next: Your freshrpms repository page looks like a
> single 3rd party repo, but it looks like the same
> packages are part of rpmforge and are managed by
> you – why don’t you even mention rpmforge on your
> homepage not to mention to advice everyone to use
>rpmforge instead of freshrpms?

Because IMHO rpmforge.net is not ready. I don’t know if it will ever be, but I like the idea, although I don’t share all the goals. For Dag, to who I left the “rpmforge.net” domain for that project, the goal is to provide as many packages as possible for as many distributions as possible. His way of doing things is also like “update, push to the masses then fix if you get reports of something that broke”… which works very often, and quite well to maintain LOTS of packages with little effort, but not if you want to keep quality very high like I’ve always tried to do with freshrpms.net.

> And, you use a rpmforge address, and you are one
> of the top 10 packagers for fedora extras. Why is
> rpmforge repacking packages which are already part
> of Fedora Extras? Examples here are airsnort,
> stellarium, dia, and so on and so on. That’s again
> doubled effort, wasted energies, and causes trouble.

I don’t maintain those in rpmforge. All the non-legally problematic (in the USA…) packages I maintain in rpmforge/freshrpms that were missing from Extras, I’ve moved to there already (proftpd, synergy, viruskiller, torcs etc.).

> The same question can be asked about Core: Why
> are packages from fedora core repackaged
> (memtest86+, mozilla, …)? Where is the use behind
> that?

Provide fixed and updated packages for older distributions when it makes sense to do so. But once again, this is rpmforge, not freshrpms.

> Btw.: I know that Fedora Extras has a strict policy to
> not cooperate with other 3rd party repos, but
> everyone can join (well, you are one of them who
> joined ;)). And I know that one aim of rpmforge is
> to provide additional packages for more than just
> fc345, but also rhel+rebuilds (centos, etc.) but it’s
> hard to see that that really excuses repackaging
> so much stuff… :/

Well, here’s how it works : rpmforge and freshrpms share the same svn repository. In there, I actively maintain only the packages I build for freshrpms.net, which Dag and Dries reuse to build also on older distributions, RHEL etc. When they add a package to rpmforge, they sometimes miss the fact that it’s already in Extras. Other times, they decide to push a package newer than the Core or Extra one because it makes sense (like recent rsync versions for old distributions)… but of course all these are arbitrary decisions, with no strict policiy to stick to.

Overall the rpmforge/freshrpms cooperation worked out quite well, since we’ve been doing it for 2 years now. The freshrpms part hasn’t actually changed, as I still provide the stuff I feel useful that isn’t present in the base distribution, but it has benefited from fixes and enhancements by Dag and Dries. The other way around is true too.

Anyway… a quick summary of the present and the future :
- Freshrpms.net _is_ a community… it’s just not “community driven”. The mailing-list has gotten much more silent ever since Extras came along, but it still counted over 600 subscribers last I checked, and any spec file patch or enhancement suggestion that make sense go into the available packages in a matter of hours or days. As an example, just today I’ve added a user-contributed power management hook script to my 855resolution package and added libmms support to gstreamer-plugins-bad as requested by a user.
- Rpmforge.net wants to become a real community driven effort. Last month, Dag and I met again at the FOSDEM and discussed many aspects with a CentOS guy, as CentOS users really appreciate Dag’s RHEL packages. The goal of rpmforge is somewhat unclear on some of the details, but the website, the subversion repository and the packages already give the main idea. From there, all people interested in helping out are more than welcome.

> So far, I hope you find time to answer these
> questions or, even better, to write a short note
> about such questions somewhere where everyone
> can see the answer because I’m certainly not the
> only one interested in these facts :)

Well… I don’t get those questions very often either… I wouldn’t answer in such length otherwise! ;-)

I hope to have cleared stuff up a little! Oh, the last detail, about my @rpmforge.net address, the reason is because I bought that domain long ago, with a vision of a huge build system (hence “forge”, but it never happended) and started using an email address on that domain. Later, when Dag wanted to turn what he was doing into a community effort, I offered the domain named to the project.

Cheers,
Matthias

I think that it clears a lot of questions, and brings a lot of new light into the whole subject!

Thanks again Matthias for this very detailed answer, it helped a lot :-)

About these ads

2 thoughts on “Compatibility and freshrpms

  1. You’re talking about compatibility within Fedora, but what is neccessary for compatibility across distros? If all major distros claim to be LSB-compliant why don’t we have universal packages? Maybe you could write something on that and clear some things up.

    Cheers

  2. I think the main problem with LSB is that the LSB is not desktop ready – yet. The LSB specifications does not say a word about the desktop enivronment libraries which has to be there to be LSB compliant. That is a feature which is expected in one of the next LSB publications.

    Unfortunately it seems that LSB is taking quite a lot of time for these adoptions – rumors are that KDE 4 will be the first version of KDE going into the LSB specs…

    But even then: if two parties are packing exactly the same package, you will face the problem of incompatibility: imagine someone packages mplayer with support for something, and the next without – they both will provide two versions of the same program which are different – even if they are packaged LSB compatible.

    But I agree with you that a usable, fully fledged LSB would help a lot in these cases: the most programmers would provide their own packages and that would make it much more easy to install 3rd party software.

    But: keep in mind that the LSB has problems with software which is strict GPL, and not LGPL…

    And because the LSB is not the fastest project ever it is probably better to check for other solutions in the meantime :-/

Comments are closed.