Summary of the 2008-04-08 Packaging Committee meeting

Nicolas Mailhot nicolas.mailhot at laposte.net
Tue May 13 07:47:42 UTC 2008


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.

> 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).

> 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

> 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.

> We should either ship repodata for JPackage in the repo, officially
> support JPackage packages, and stop repackaging JPackage packages for
> Fedora or we should stop pretending that it's a goal of ours for
> people to be able to switch out the Java stack provided by Fedora
> with the Java stack provided by JPackage,

And I want a pony. The current situation is that way because there are
not enough Java packagers both Fedora and JPackage-side, so we share
efforts, and any alternative that requires more manpower we don't have
is going to result in a worse situation for our users. I mean, we have
not even managed to package major eclipse plugins like WTP so far, and
eclipse is a important but very small part of the FLOSS java code out
there.

-- 
Nicolas Mailhot




More information about the fedora-devel-list mailing list