Re: Summary of the 2008-04-08 Packaging Committee meeting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Callum Lerwick wrote:

1) JPackage predates Fedora and it's predecessor in interest fedora.us.


And what does that have to do with engineering integrity? Overlapping repos
are broken, period. Is anyone not convinced of this? Do I really need to go
over the reasons why?

It takes two participants to maintain an incompatibility.

> I'm sorry, seniority is no justification.

How so?  The forked duplicate is clearly the problem.

And JPackage
only has seniority if you conveniently ignore the fact that Fedora is an
evolved form of Red Hat Linux and not an entirely new project.

I don't quite know what that means or how it relates to all the other distributions it supports. Or why it should be relevant to the act of forking incompatible, conflicting duplicates of its packages.

2) The packages that are in question come from JPackage and were
imported into Fedora (hence the jpp in version string).


And? So continue keeping the Fedora package in sync with JPackage.

If they are exactly identical there's no conflict.

3) Most of the JPackage repository is contained in generic, which has
a goal of being the same set of packages for all distributions we
support.  Only JNI code (or similar) is in the distribution specific
repositories, so removal of packages that conflict with Fedora from
the generic repo harms our user base that is not on Fedora.


Set up your build system to maintain symlinks to everything in the "generic"
repo in the Fedora-specific repo, *except* for what exists in Fedora. Then
point Fedora systems at *only* the Fedora-specific  repo. > Ta da, fixed.

Wouldn't it have been better to not break it in the first place?

4) JPackage does not support Fedora exclusively (nor do we intend to),
we support Mandriva, OpenSuSE, etc.


Red herring.

What??? Why should the rest of the world cater to fedora's non-standardness?

5) JPackage is not beholden to the Fedora project in any way, so you
aren't allowing anything.  We are an OSS project, just like Fedora is,
except we focus on something different than an entire OS.<https://www.redhat.com/mailman/listinfo/fedora-devel-list>


 Neither is Fedora beholden to JPackage.

Unless, of course, you cared about your users whose ability to get the packages you didn't bother to copy, due to policy issues or whatever, has been broken.

> I'm not sure what your point is. If
JPackage insists on Doing It Wrong, that's their problem, not ours. I just
gave you a possible solution.

The point is clearly that the repository creating the new incompatible forked copy of a package is the one causing the problem and the one that should have done it some other way. This would be sort-of irrelevant if the copying repository took copies of everything and fixed up the incompatibilities internally in their own version, but that hasn't happened with any of the repositories the fedora project has abused this way, leaving the users who need access to the other content hanging.

--
  Les Mikesell
   lesmikesell@xxxxxxxxx


--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux