Hi, I have a question regarding packaging for Fedora.
I want to package an application that depends on jets3t. It is packaged in Jpackage. I see in fact that many Java packages are available in JPackage.
What is the usual behavior in this case ? Should I check with maintainer if package can be "moved" to Fedora ? (and do it myself if he does not wish to do so)
There are Fedora "core", EPEL, JPackage... it is not really clear for newcomers to see several repository, and what are their relationships...
Thanks
Olivier
On Sun, Aug 21, 2011 at 01:24:16PM +0200, Olivier Sallou wrote:
Hi, I have a question regarding packaging for Fedora.
I want to package an application that depends on jets3t. It is packaged in Jpackage. I see in fact that many Java packages are available in JPackage.
What is the usual behavior in this case ? Should I check with maintainer if package can be "moved" to Fedora ? (and do it myself if he does not wish to do so)
You can. JPackage is somewhat cross-distro so they may not want to get it into Fedora. If so, you are quite free to try to get it into Fedora itself. The Java packaging guidelines have evolved over time (but at one time the jpackage and Fedora Guidelines were very similar, I don't know if they've remained so or not) so you may have to do some adaptation of the jpackage spec before it will pass Fedora review.
http://fedoraproject.org/wiki/Packaging:Java
There are Fedora "core", EPEL, JPackage... it is not really clear for newcomers to see several repository, and what are their relationships...
There is just Fedora now that Fedora supports for Fedora. EPEL is a Fedora project to build addon packages for RHEL, CentOS, and similar distributions. JPackage and other repositories are third-party projects that may make an effort to create packages that run on Fedora and may share some contributors in common but are largely independent.
-Toshio
On Sun, 2011-08-21 at 13:24 +0200, Olivier Sallou wrote:
There are Fedora "core", EPEL, JPackage... it is not really clear for newcomers to see several repository, and what are their relationships...
Since your are french, I would invite do check out the french documentation on http://www.fedora-fr.org Most repositories have their own page with a description of their content and how they can be used and the main repositories are described in the yum documentation page.
Pierre
Excerpts from Olivier Sallou's message of Sun Aug 21 13:24:16 +0200 2011:
Hi, I have a question regarding packaging for Fedora.
I want to package an application that depends on jets3t. It is packaged in Jpackage. I see in fact that many Java packages are available in JPackage.
What is the usual behavior in this case ?
Usual course of action currently is to package it from scratch in Fedora. We have diverged considerably from JPackage over time (especially during last year). On one hand it's bad because we can't copy things from jpackage anymore, but it made several packaging tasks easier. Plus we have more strict rules as far as bundling/licensing reviews are concerned.
Should I check with maintainer if package can be "moved" to Fedora ? (and do it myself if he does not wish to do so)
Maintainer of jets3t in JPackage has most likely no relation to Fedora. But you are free to ask obviously :-)
There are Fedora "core", EPEL, JPackage... it is not really clear for newcomers to see several repository, and what are their relationships...
Others have covered this mostly. I'll just add that JPackage is a cross-distro project to create rpm packages for java software. We used to be much closer, but diverged significantly.
If you need help with specific java packaging questions feel free to visit #fedora-java on Freenode (or write to java-devel mailing list).
-- Stanislav Ochotnicky sochotnicky@redhat.com Software Engineer - Base Operating Systems Brno
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
Le Dim 21 août 2011 13:24, Olivier Sallou a écrit :
What is the usual behavior in this case ? Should I check with maintainer if package can be "moved" to Fedora ? (and do it myself if he does not wish to do so)
If done cleanly importing packages from JPackage to Fedora is fine and will be welcome from everyone, JPackage maintainer included.
The mistake to avoid is to fork the package and apply Fedora changes blindly without discussing them with the original packagers, as you may introduce bugs that will be reported JPackage side and make users and JPackage people very angry at you - the first ones because you'll break all the mised JPackage+Fedora installs that exist in the field as soon as they get your package as update, the second ones because they'll get problem report through no fault of theirs and that they can't fix since the problem will be in your package.
The best option is to arrange to become a kind of co-maintainer JPackage-side. This way you'll be able to push relevant information from one project to the other when necessary. This is how rpmfusion packagers synchronize with Fedora packages they depend heavily on.
Even though Jpackage is a much smaller project than Fedora it includes a lot more Java packages so it's coverage of Java packages interactions will tend to be better than the Fedora one.
On 14:19:51 Monday 22 August 2011 Nicolas Mailhot wrote:
Le Dim 21 août 2011 13:24, Olivier Sallou a écrit :
What is the usual behavior in this case ? Should I check with maintainer if package can be "moved" to Fedora ? (and do it myself if he does not wish to do so)
If done cleanly importing packages from JPackage to Fedora is fine and will be welcome from everyone, JPackage maintainer included.
The mistake to avoid is to fork the package and apply Fedora changes blindly without discussing them with the original packagers, as you may introduce bugs that will be reported JPackage side and make users and JPackage people very angry at you - the first ones because you'll break all the mised JPackage+Fedora installs that exist in the field as soon as they get your package as update, the second ones because they'll get problem report through no fault of theirs and that they can't fix since the problem will be in your package.
The best option is to arrange to become a kind of co-maintainer JPackage-side. This way you'll be able to push relevant information from one project to the other when necessary. This is how rpmfusion packagers synchronize with Fedora packages they depend heavily on.
Even though Jpackage is a much smaller project than Fedora it includes a lot more Java packages so it's coverage of Java packages interactions will tend to be better than the Fedora one.
Nicolas, while this was true things have changed dramatically last year and Fedora is now what JPackage was in the past - the place where development happens and most other distros are basing their work on Fedora and I bet that one would easily find that even JPackage maintainers are using Fedora's specs as a base for their packages. We now ship a lot more uptodate software in Fedora and generally speaking what is in Fedora now is not yet reproduced in any other RPM-based distro except some EE related libs. But things are changing rapidly in this area too - https://fedoraproject.org/wiki/JBossAS7 . Fedora might even be the first to ship JBossAS7 - in a true community manner - synced with the rest of the distro :). This mail is not trying to diminish the significanse of JPackage in forming the initial packaging base for the Java stack but to point that Fedora and JPackage took different roads: - JPackage cares for EE usecases while Fedora is more conserned about development tools and end user apps(freemind, jmol, josm...) - JPackage is trying to produce huge compat platform trying to run any EE platform, Fedora is trying to unify the stack by spending a huge amount of time helping upstream move away from ancient libs, build practices and etc. I can continue listing examples but these 2 alone should be enough for everyone to see that the projects are departing more and more and that if you have that different goals you would hardly find common ground.
Regards, Alexander Kurtakov
Le Lun 22 août 2011 13:42, Alexander Kurtakov a écrit :
Nicolas, while this was true things have changed dramatically last year and Fedora is now what JPackage was in the past ...
Fedora might even be the first to ship JBossAS7 - in a true community manner - synced with the rest of the distro :).
It would be really nice to finally get to this point. Kudos to everyone who contributed to this goal!
I can continue listing examples but these 2 alone should be enough for everyone to see that the projects are departing more and more and that if you have that different goals you would hardly find common ground.
As a former contributor to both projects I will say the common ground is easy to find; users want stuff to just work and do not care about politics. The EE/not-EE separation is quite arbitrary and unfortunately too often used to paper over problems that come back with a vengeance later. Good pieces of work are used both sides of the fence without complains; only incomplete pieces try to pretend they belong to one side only.
So let's just be all friends and work together.
On 13:24:10 Tuesday 23 August 2011 Nicolas Mailhot wrote:
Le Lun 22 août 2011 13:42, Alexander Kurtakov a écrit :
Nicolas, while this was true things have changed dramatically last year and Fedora is now what JPackage was in the past ...
Fedora might even be the first to ship JBossAS7 - in a true community manner - synced with the rest of the distro :).
It would be really nice to finally get to this point. Kudos to everyone who contributed to this goal!
I can continue listing examples but these 2 alone should be enough for everyone to see that the projects are departing more and more and that if you have that different goals you would hardly find common ground.
As a former contributor to both projects I will say the common ground is easy to find; users want stuff to just work and do not care about politics. The EE/not-EE separation is quite arbitrary and unfortunately too often used to paper over problems that come back with a vengeance later.
The only real problem that causes the separation is that the so called EE things tend to stay with anciend libs and don't want to move to newer libs for various reasons while development tools are eager doing that causing people complaining either for shipping too newer or too old version. And with the current manpower we took the side of the newer versions, read as we don't take care for compat libs but others are free to do so. Yet this is causing a lot of disruption but this is the same problem we have seen with KDE4, Gnome3, systemd and what not so nothing special but still this is the dividing line we see.
Good pieces of work are used both sides of the fence without complains; only incomplete pieces try to pretend they belong to one side only.
So let's just be all friends and work together.
I fully support this and we try to work with everyone that wants to work with us (but not giving orders of course ;)
Regards, Alex
Alexander Kurtakov wrote:
complaining either for shipping too newer or too old version. And with the current manpower we took the side of the newer versions, read as we don't take care for compat libs but others are free to do so. Yet this is causing a lot of disruption but this is the same problem we have seen with KDE4, Gnome3, systemd and what not so nothing special but still this is the dividing line we see.
At least in the KDE case, we're trying really hard to support compat stuff. In fact, we still maintain kdelibs3, whereas most other distros have dropped it by now, even Debian. (And I can tell you that I have no intention whatsoever to drop it, even when we'll have the KDE Framework 5 coming. It is almost no effort to keep kdelibs3 working, just the odd FTBFS issue from time to time.) We also ship a kdebase3 containing things like the KonsolePart or the kprinter utility, something other distros aren't/weren't doing either.
Kevin Kofler
On Tue, 2011-08-23 at 10:55 +0200, Nicolas Mailhot wrote:
As a former contributor to both projects I will say the common ground is easy to find; users want stuff to just work and do not care about politics. The
Unfortunately, whenever this statement is made, the definition of 'politics' turns out to be 'the boring underlying stuff you have to do to deliver stuff in a manner such that it just works for users'.