On Wed, Nov 13, 2019 at 10:04 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > On Wed, Nov 13, 2019 at 6:18 AM Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote: > > > > > > > > On Wed, Nov 13, 2019 at 3:17 AM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > >> > >> Aleksandar Kurtakov wrote: > >> > So people would prefer no packages at all over packages in modules? > >> > >> I see 2 reasons so far why some packages are module-only: > >> 1. because a dependency of the package is module-only. That is exactly what > >> we want to prevent by proposing a ban on module-only packages. > >> 2. because the maintainer wants to maintain only one version and chose the > >> modular one. Banning module-only packages will hopefully get the > >> maintainer to either maintain the non-modular version instead or to > >> maintain both versions after all. > > > > > > Here you seem to be missing the third option packager may choose - maintain none of them and say bye to Fedora. Which IMHO is the most likely outcome of all this. > > Hi Aleksandar, > > I agree that this has not gone well for both eclipse and its > maintainers in fedora. > > I'm also a bit surprised that none of the current eclipse maintainers > has approached the Stewardship SIG and asked for help. > I think we could have prevented the worst problems for non-modular > eclipse (at least the core packages), but we just didn't know what to > do (and nobody told us). > > While it might be too late now, an offer to help with making > non-modular eclipse packages work again (if that's even wanted > anymore) is on the table. > Right now, we just don't have the knowledge and manpower to do that > alone and without input from eclipse maintainers. > > We probably should also start looking into the derelict Java SIG - > starting with pruning of members that are now AWOL, and updating the > Wiki page to actually reflect the current state. I think there > definitely *are* people who are interested in keeping (non-modular) > eclipse packages working, but - like us - they probably don't even > know where to start. Reviving the Java SIG might be a way to herd the > cats into the right direction. > > Fabio And, while I'm here, I should also raise some complaints (this is the Complaint Thread, after all) ;) The situation where both modular and non-modular versions of a package exist are .... problematic. user-system problems: - It's not always clear which incarnation of a package will get installed on a user's system. do they have to explicitly enable a module, or can that happen silently? - It's unfair to maintainers of "ursine" branches, since their beautiful, up-to-date, packages that are filled with security patches will just get shadowed by modular versions, regardless of package versions. - What if the modular and non-modular branches have made incompatible changes since the branches diverged? For example, the modular branch has disabled some features that are still enabled in the ursine branches because other ursine packages rely on them. I assume the modular version will trump here and break ursine packages? - What if modular (or ursine, direction doesn't matter) branches include major version upgrades, which necessitate either other package updates or patches in other packages? Will this lead to conflicts, or broken packages? development / build-time problems: - What if a package is provided as both ursine and modular package, and Ursa Prime is enabled for a module that contains this package? - Will the modular version of the package always override the ursine one, regardless of package version? - What about incompatible divergence, major version differences, or "System-Wide Changes" (same problem as on user systems explained above)? I've raised most of these concerns now multiple times over the past few years, but I never got a complete answer, or no answer at all. Fabio > >> > >> > >> > I ask this as the traditional rpm way of doing is simply not working and > >> > that's the reason why many of us (old time Java packagers) just gave up, > >> > it's purely impossible to satisfy the needs of multiple "major" packages > >> > with same set of dependencies. > >> > >> It is very much possible, just ship parallel-installable compatibility > >> packages. For Java JARs, you can simply ship the non-default versions as > >> name-version.jar (which is actually how most upstreams ship their binaries > >> as well) rather than just name.jar, then they won't conflict. (Of course, > >> the package name has to be suffixed with the version as well, as for all > >> compatibility packages.) > >> > >> Using modules for that purpose is broken by design because you are just > >> pushing the problem from the packager to the end user, who will not be able > >> to install the 2 unrelated packages on the same machine due to conflicting > >> dependencies. > >> > >> Kevin Kofler > >> _______________________________________________ > >> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > >> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > -- > > Alexander Kurtakov > > Red Hat Eclipse Team > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
