[Fedora-packaging] [Fwd: [JPackage-discuss] Moving jpp# to Provides:]

Jesse Keating jkeating at redhat.com
Tue May 20 03:09:02 UTC 2008


I sent this over to the jpackage discussion list after a lengthy talk on
IRC with a few Fedora and jpackage folks.  So far there hasn't been any
response other than some clarification of the rpm level drawback of
using Provides.  I thought I would toss it over here for some
consideration on our side of things.

-------- Forwarded Message --------
From: Jesse Keating <jkeating at redhat.com>
Reply-To: Discussion about JPackage project <jpackage-discuss at zarb.org>
To: Discussion about JPackage project <jpackage-discuss at zarb.org>
Subject: [JPackage-discuss] Moving jpp# to Provides:
Date: Mon, 19 May 2008 16:05:01 -0400

In trying to find a compromise for jpackage packages in Fedora, we asked
somebody from the jpackage side to provide a list of technical reasons
why 'jpp#' needed to continue to be in the Release: string of an rpm.

Deepak provided us with
http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP

In reviewing this and in the various arguments that have happened over
the past few years surrounding the jpp vendor tag, I think I've struck
upon something that just may work, at least work to the best of the
requirements that I know of.

If we simply move the 'jpp#' part of the release string to a Provides:
line in the spec file, here is what happens:

Exclusion of jpp* from a specific repo can still be done, since excludes
work upon Provides too.  It can be even more precise since currently a
package with the name of foolalajpp4me would trigger the excludes and
cause problems.

Deploying an entire jpackage stack is still possible.  This is actually
better accomplished at the yum repo level.  yum --disablerepo=\*
--enablerepo=jpackage install \*  <-- that will install everything from
jpackage, which I am understanding is the goal of this data point.

JPackage is still given credit as the package provides jpp, has the jpp
changelogs, can have # comments regarding the jpackage interaction,
summary, description, etc...

Grouping by jpp is still possible.  yum --disablerepo=\* --provides jpp*

----

A current drawback to using jpp# is that the '#' can change, so using
rpm itself becomes more tricky as rpm doesn't accept globs.  That said,
instead of doing jpp# you could just do 'jpp' and then rpm would be able
to do things like:

rpm -q --whatprovides jpp

and well, whatever you want to do with that output.

However if you wanted to keep the versioning information, and still
retain the ability to query on 'jpp', you could do:

Provides: jpp = # 

or =< if that fills your needs.  Since rpm does handle versioning in
Provides you can still do rpm -q --whatprovides jpp and that will work.

Anyway I'm drifting a bit here, but I did want to start a conversation
about the feasibility of using Provides to accomplish the listed goals
rather than added characters in the release string.


I should also note that for best results, this Provides should
be /added/ at both the jpackage and Fedora level.  Removal of the jpp#
information from release string technically only needs to be done at the
Fedora level, it could remain at the jpackage level if so desired.  The
existence of "jpp#" can easily be controlled by a %{_dist} like tag in
the release string.  In jpackage build roots that value can expand to
'jpp#' and in Fedora buildroots that value would expand to '.fc#'.
Since the other version-release parts should be used for version
comparison it shouldn't much matter if jpp# is on the jpackage side
and .fc# is on the Fedora side.
 
_______________________________________________
JPackage-discuss mailing list
JPackage-discuss at zarb.org
https://www.zarb.org/mailman/listinfo/jpackage-discuss
-- 
Jesse Keating
Fedora -- Freedom² is a feature!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20080519/2c63944e/attachment.sig>


More information about the Fedora-packaging mailing list