Summary of the 2008-04-08 Packaging Committee meeting

[Toshio Kuratomi]

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