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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
