Nicolas Mailhot wrote:
Le mardi 13 mai 2008 à 08:50 -0700, Toshio Kuratomi a écrit :
Nicolas Mailhot wrote:
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.
Well, organise yourself and prove this third-party repository value. JPP
has nothing to prove. It antedates Fedora.
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
This has always been the case. FLOSS project, contributors decide, some
Red Hat/Fedora people are major JPackage contributors. The problem is
not there is no presence, or that this presence is ignored, but that
this presence is not used at all by the Fedora instances.
You'd be hard-pressed to find one message on this subject by the people
that want to force this change on the public jpackage list where most of
the people needing convincing are. You do have a few messages by Red Hat
people who are hard pressed to defend a change they didn't propose or
adhere with.
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.
We can stop saying that that won't magically create alternative packages
Fedora side.
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.
Sure it's a danger but is it worse than having to reinvent the wheel
twice as a complete fork and separation would lead to? (assuming both
branches do not deperish for lack of contributors)
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.
Note it has never been the goal to "hoard" packages jpp-side. They can
flow Fedora-way as long as Fedora changes are pushed back where
non-Fedora packagers may use them and the two repositories do not
painfully diverge.
Yep. And I'm just saying that divergence is inevitable (as seen by the
tomcat package) if we keep going forward in the way we are now. We need
to either get closer to JPackage or farther away. We have a choice
right now of which way to go. We should think about which direction
makes the most sense and form policy that commits us to that.
-Toshio "Grape in the middle of the road get squashed" Kuratomi
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
