Hi all,
At Jesse's request, I took a look at the Wiki page in
http://fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming
"Naming Conventions for Packages Adapted from JPackage"
Of course, some time has passed and things have already evolved, so I
will try and update the text. Please comment and lets see how we should
update the Wiki page.
1) Problem Space
"Many Java programs are first packaged by the [WWW] jpackage project. In
essence, the Fedora packages have two upstreams: The upstream project
itself and the jpackage project's spec file and patches. Fedora imports
a package from jpackage and makes changes to enable native AOT
compilation via gcj and bugfixes that have not been merged into either
of the upstreams."
> Well, The last sentence is no longer true. The AOT compilation bits
were propagated upstream, so all the Java team has to do now is to
import the upstram package as is and build. We still need to make any
changes to the code to circumvent GCJ shortcomes, but these are so rare
nowadays that almost all packages build without any changes at all.
> As a consequence, fixes have been made on the usptream version, which
is them re-imported, and we've been also reimporting when fixes are
applied upstream comming from the other JPackage-based distros or from
direct JPackage users feedback.
"Presently, Core's jpackage-based packages have reflected the package
origin within the package Release: 1jpp_2fc In this scheme, the 1jpp is
the upstream jpackage release, _ is a separator, and 2fc is the Fedora
release. (Note, this scheme is not currently as defined as the Fedora
Naming Guidelines. So there are some practices above the base standard
that would need to change.) This scheme has two expressed goals:"
> OK, here we have made much progress:
a. The "_" character has been removed and replaced by a '.'
b. The "fc" string has been removed
c. All FC6 packages have been rebuilt to comply with a and b above
d. An initial agreement has been reached to also compatibilize the
pre-release cases, with JPackage adopting a Fedora-like order.
> Summary: It all comes down now to the remaining ".NNjpp" in the
release which indicates the upstream version that was last imported
(sync point you could call it).
In the case of the goals, I think the original ones in the week were not
correct in the first place. Lets try again:
" 1. Allow for upgrading between the Fedora and JPackage repositories
so that upgrade paths similar to the following works:
*
java-foo-1.0-1jpp_2fc [Fedora Release]
java-foo-1.0-2jpp [Updated JPackage Release]
java-foo-1.0-2jpp_3fc [Updated Fedora Release rebased
against the new JPackage]
3. A third expressed goal that conflicts with 1. is to upgrade
Fedora packages only with Fedora packages and jpackage packages with
jpackage packages."
> These two goals can be made into a single one, lets say: "flexible
upgrade paths".
> There is no conflict whatsoever -- we currently do all these:
a. Both Fedora and JPackage (what is stated in 1, i.e., newest release
globally) by leaving all repos enabled (both fedora-core and jpackage)
b. Fedora only by disabling the jpackage.repo
c. JPackage only by using --exclude=*jpp* --excluce=eclipse* when
upgrading from fedora-core.repo and enabling only the jpackage.repo for
the Java packages update (people play with --enablerepo for that management)
"2. Allow users and packagers to tell what JPackage release the
java package was based against."
> This is very important to us (Java team). We can quickly identify if
the version we have already has a fix or not, among other things.
I will have to add a goal that was not stated in the initial Wiki, lets
call it 4:
"4. Allow the switching of Java stacks as a whole"
> This is currently accomplished by using regular expressions based on
the *jpp* and eclipse* patterns.
> This is useful for development so we can try sets of packages built
with a different compiler for instance, without having to change all
spec files to bump releases, and to revert the system to the original
state afterwards. We use this a lot.
> There are also users that want to switch the collection of Java
packages to use a set compiled with a proprietary JDK for instance
(maybe a different version of Java), or something provided by the
software vendor of some major component they bought.
OK, now the Wiki page states:
"Which naming guideline is chosen depends in large part on whether these
are judged to be worthwhile and attainable goals."
> Which I think is correct.
Discussion of the goals
"Goal #1
If JPackage were truly an upstream then we wouldn't want users to
upgrade Fedora Packages with JPackage. We have bugfixes, local changes,
and other patches that we add to packages to make them work better on
Fedora. Having users upgrade between upstream and our packages is not a
goal with any other upstream. gbenson states this [WWW] here although he
phrases it in the specifics of Fedora/JPackage instead of the general
Fedora/Upstream."
> We don't do anything to make packages run better on Fedora. We do
pre-compilation, which does help in the startup time. But there is no
real harm in revert to a bytecode-only package to get an upstream fix
until it shows up in pre-compiled form in a Fedora update.
"There could be times when the jpackage naming is not compliant in the
name, version, or release fields. When this happens, we would not be
able to attain this goal. For instance:
cryptix-asn1-20011119-4jpp_2fc.1.1.src.rpm. The version field must be
changed before importing otherwise the final release of cryptix-asn1-1.0
will not upgrade the package."
> That was a wrongly versioned package from an older JPackage release.
The maintainer was informed and the problem was fixed. It is now
cryptix-3.2.0-9jpp. In general, we have had no problems in getting this
kind of things fixed. I think this comment can be removed.
"Goal #3
This is not truly implementable via the package release tag.
Separating the native libraries into a subpackage might have some
bearing on this."
> Yes it is implementable, as shown above.
"Goal #2
Users shouldn't need this information. The Fedora Package may have more
fixes than the JPackage one. It may be synced with more upstream
bugfixes. It may contain snapshots of JPackage work that haven't hit the
repositories yet because JPackage is working on a new major release. If
the package works without bugs then the end user is happy."
> Putting a set of compatible packages together is a major endeavor.
The Java team, as well as the folks from Mandriva and Suse have been
basically polishing the sets that have been created upstream.
> Also, we make the fixes/changes upstream first, then import. This
way we benefit from feedback from people (both packages and Java users)
who know deeply some of these Java software libraries.
> Again: updating paths are optional, and it is up to the user to
choose. The current naming only allows that to be done if so desired,
which would be otherwise not possible.
"Developers can use this information. But they aren't going to be
staring at the package name most of the time. When they checkout from
cvs, they'll have a spec file, not an RPM so the filename is no help.
They have to look inside the spec file at which point it's just as easy
to put the information in the %description, a Provides, or a comment.
Using a Provides makes it queryable from the rpm command line as well."
> The way we do now is by "rpm -qa | grep jpp" and variations. Or
similar pattern usage in the repos. We don't need to look inside the
spec file to know that the base for that release was a specific upstream
release.
> Using things like "Provides" for things that are not their original
goal would be abusing that feature, and the information for that is used
by depsolvers and such. We should stay away from that. In a lesser
degree, maintaining a release in the description is not convenient and
error prone, and does not address the other goals anyway.
The Wiki page then has some proposals, which I would prefer to discuss
each one separately once we agree on the goals.
Regards to all,
Fernando
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
