Nicolas Mailhot wrote:
Le Mar 13 mai 2008 08:26, Toshio Kuratomi a écrit :
Nicolas Mailhot wrote:
Le lundi 12 mai 2008 à 15:48 -0400, Tom "spot" Callaway a écrit :
* I'm not mandating that JPackage change anything. This is
specifically
targeted on handling the Fedora packages which are derived from
JPackage
packages.
That's not realistic, if you want your matching to work you need the
tagging implemented both sides. The Fedora side is the easy one.
Fedora
has still not merged the bulk of the JPackage repository.
Either I'm reading this page wrong:
http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP
or there's additional rationale for .jpp that's not on that page.
The only thing I'm seeing from that page is that people want to select
the Fedora packages on their system that have a companion package in
JPackage so that they can either remove the Fedora package in favor of
the JPackage version or in order to see which packages originated in
JPackage.
The selection process is of course symetric, like any rpm/yum op.
Users basically switch back and forth between the two java stacks till
they find the one that works best for them.
That's interesting because it would be a place that the current use of
.jpp fails, then. .jpp can't be used to differentiate between the
Fedora provided stack and the JPackage provided stack as they're both
using it.
There's no reason that I see listed on that page for
JPackage
to rebuild with a new group/vendor. In fact, if JPackage were to
rebuild with the same group it would defeat the purpose of including
that group.
If you want to select on group as it is proposed now you need to put a
unique group in the specs jpp-side too (group that won't be the same
as the fedora one).
Well, if you just want to tell where a package came from vendor would
certainly work. But the page doesn't say that. It says it wants to
tell where a package came from before it came to Fedora. Or where it's
provided in addition to Fedora. Or even, where we support you mixing
with an additional repository.
I'm not saying that .jpp has to go, but I will say the .jpp-in-Fedora
exception was explicitly given a limit when it was voted in that
revolved around the selection issue being resolved in another manner.
I think the java group has already said it would implement changes
when a solution is presented. (not because the technical arguments
presented were convincing, just to have Fedora instances grind some
other axes). And I'd be the first to advocate expending energy just to
make some packages a bit cleaner. However, sitting on the fence there
and having worked both sides I'm just a bit affronted that we're happy
asking a lot of efforts of others to replace a harmless kludge, and
the solution presented scores no better in the cleanliness scale (in
fact since it's very new and quirks bits no one touched before it
could very possibly end up much worse).
a lot of efforts is asked of others in the name of purity, an
Yeah, using Groups for this strokes me the wrong way too. However,
nothing is being asked of other people as the .jpp tag currently does
not allow you to select only the packages which are from JPackage. If
that's something that is desired, a plugin that uses the Vendor tag will
certainly work. But just because it is used for the JPackage packages
selection doesn't mean it must be used for the "Fedora packages derived
from JPackage packages" selection.
Some of the base assumptions on the ReasonsForKeepingJPP also don't
seem
to be in line with past thinking about third party repositories. We
don't support people installing an rpm provided by an upstream on
sourceforge if it's newer than the one in Fedora and back and forth.
We don't support people ...
We don't reuse extensively the work done in those repositories. So
wrong comparison here.
Not really. The argument seems to be that there's not enough java
packagers to fill both JPackage and Fedora with rpms. But this is no
different than anyone else who says, there's only a few of us who care
about packaging OCaml programs/Lisp programs/vim plugins and there's too
many useful pieces of software written in that language that users want
for us to handle. Make accomodations for us so that users can decide to
make use of this third party repository where upstream/other distros can
help us with the packaging effort.
Either we decide that JPackage is special because it has guidelines for
packaging that we agree with, our java packagers mostly work in that
repository anyway, (to re-emphasise what you've said) "we reuse
extensively the work done [in the JPackage repository]", and we have a
presence there that allows us to make changes to JPackage guidelines and
policies when there is a need or we stop saying that it should be a goal
that our users can switch out the Fedora stack with the JPackage stack
on any arbitrary update.
What we have now makes no sense:
1) JPackage derived packages are supposed to be switchable with Fedora
packages on a per package basis (per the original justifications for the
.jpp exception)
2) JPackage derived packages are supposed to be switchable with Fedora
packages on a whole stack basis (per ReasonsForKeepingJPP).
3) We could have packages in Fedora that have a counterpart in JPackage
but are not derived from the JPackage package with no rhyme or reason
beyond whether the packager was active in JPackage when they made the
submission. This will cause problems for people attempting to mix
JPackage and Fedora stacks as per #1.
4) JPackage Guidelines only have a few points of divergence with the
Fedora Guidelines and the stated goal of our java packagers is to make
those divergences disappear.
5) The attitude that our users can find a package in JPackage if it's
not in Fedora is detrimental to us. Where ever possible, we don't want
user's to have to *find* packages, we want them to be able to yum
install the package out of the box.
-Toshio
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
