Hi,
I am filing a ticket according to https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-defaults/ to add a default stream for the Eclipse package.
I would like permission to make the eclipse:latest the default stream.
Eclipse is no longer buildable in the base-distro, so I am going to retire it there. I would like this default stream upgrade users smoothly from base-distro packages to modularity packages.
Why don't we make eclipse buildable in the base distro instead? What benefit does modularizing eclipse bring to the Fedora users and contributors (other than eclipse maintainers)?
This change would make jspecview FTBFS, how do you plan to coordinate with jspecview, will it be modularized as well, retired, or the dependency dropped?
Oh, correction, there are more subpackages of eclipse and more affected packages:
$ for pkg in eclipse eclipse-contributor-tools eclipse-equinox-osgi eclipse-jdt eclipse-p2-discovery eclipse-pde eclipse-platform eclipse-swt eclipse-tests; do echo "# $pkg"; repoquery --repo=koji-source --whatrequires $pkg 2>/dev/null | pkgname; echo; done # eclipse jspecview # eclipse-contributor-tools eclipse-cdt eclipse-pdt # eclipse-equinox-osgi # eclipse-jdt eclipse-anyedit eclipse-checkstyle eclipse-egit eclipse-linuxtools eclipse-testng eclipse-webtools # eclipse-p2-discovery eclipse-mpc eclipse-pdt eclipse-pydev # eclipse-pde eclipse eclipse-cdt eclipse-color-theme eclipse-dltk eclipse-dtp eclipse-ecf eclipse-eclemma eclipse-emf eclipse-epp-logging eclipse-findbugs eclipse-gef eclipse-launchbar eclipse-moreunit eclipse-mpc eclipse-mylyn eclipse-pdt eclipse-ptp eclipse-remote eclipse-swtbot eclipse-webtools # eclipse-platform eclipse-abrt eclipse-cdt eclipse-egit maven-eclipse-plugin tycho # eclipse-swt azureus jfreechart jogl2 tuxguitar # eclipse-tests
Why don't we make eclipse buildable in the base distro instead?
Because I'm not willing to maintain the whole ursine maven stack in the distro. The stewardship SIG do a grand job keeping ursine maven alive but realistically it is being improved and maintained properly in modularity only.
Eclipse has build and runtime requirements on maven, so I am following suite. This way I can maintain one branch of Eclipse packages instead of maintaining one branch per Fedora release.
What benefit does modularizing eclipse bring to the Fedora users and contributors (other than eclipse maintainers)?
My users already complain that ursine Eclipse packages are broken. Enabling a smooth shift to modularity packages would be a vast improvement over the current situation.
I am not familiar with jspecview. However, I wonder how it depends on Eclipse:
$ sudo dnf repoquery --requires jspecview Last metadata expiration check: 0:04:13 ago on Wed 25 Sep 2019 16:00:19 BST. icedtea-web java jpackage-utils
Haha, I checked and it actually doesn't, at all.
I removed the BR in this commit: https://src.fedoraproject.org/rpms/jspecview/c/5c12ccc55fbfacbc4b2c4f304bb4875a8c0fa599
And rebuilt for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1389944
I don't blame @mbooth here as I see he's clearly just trying to get something that works out of this, but I must say that I am very much against modulrizing more stacks just to keep up with the other modularized stacks that broke the regular packages.
This is a domino effect of poor planning. We need to stop.
Regarding the list of affected packages, excluding the ones that are already part of the module, or ones that should be retired and installed through Eclipse's market place instead of RPM, that leaves the following list:
For the last four that require the SWT library only (they don't actually require the Eclipse IDE or the Eclipse Platform) we can perhaps create a new standalone "swt" ursine package that contains this library only. IIRC we can build it simply with ant and gcc
Sounds great!
Two important things to consider here:
@mbooth This means that if you truly have any buildroot-only packages in your module, you will need to add their output to the data.filter.rpms section so they don't end up in the repo or else you will need to maintain it.
data.filter.rpms
1 .Ursa Major is coming soon (I thought we'd have it by now, but it's imminent). Once it lands, all modules with a default stream will have their built (and non-filtered) artifacts appear automatically in the non-modular buildroot.
Yeah, ursa major has been Coming Soon™ for more than a year; it's part of why I am such a late-comer to the modularity party and in a decade of package maintenance this year was the closest I came to failing to ship a working Eclipse in Fedora at all, so you'll forgive me for not hanging my hat on that possibility :-)
(An aside: I've developed a RHEL 8 requirement for Eclipse since then which I can meet by using the Fedora module as the upstream for a RHEL module, but I guess that's not strictly relevant to Fedora discussion.)
After discussion between FESCo and the Modularity WG, we've decided that Fedora will need to have a policy that all packages that are installable from a default module stream must follow all maintenance and compatibility rules as a non-modular package.
FWIW, I am not maintaining, and do not plan to maintain, my modularity packages any differently to how I maintained them as non-modular packages.
This is why tycho and pals are segregated into a separate module altogether. Think eclipse is to tycho what maven is to javapackages-tools
eclipse
tycho
maven
javapackages-tools
Additional aside: If usra major is coming really-really-soon-for-suresy-this-time-we-promise then I probably don't have to care about supporting SWT in the non-modular space for Azureas and friends, right? ... Right?
We will probably activate it for F32/Rawhide first, so you may need to support it for F30 and F31, I'm afraid.
So assuming we are getting Ursa Major, can eclipse just stay in regular Fedora? Will it blend build?
It's kinda too late for that. Many of my deps already exist in modules only (were retired from the ursine distro.)
And those deps won't be part of ursa major? What am I missing?
To quote @sgallagh:
Once it lands, all modules with a default stream will have their built (and non-filtered) artifacts appear automatically in the non-modular buildroot.
My build deps, tycho and javapackages-tools modules do not (will not) have a default stream and therefore will never appear in the non-modular buildroot.
Sigh. I'd rather see that problem fixed then modularize more and more packages.
However, I'd like to hear what other FESCo members think.
I understand that PoV, but that's not really what I intended this ticket to be about (and the work has been done already as I had no other choice). I just want to fix upgrade paths for users by setting a default stream.
Unfortunately, preventing new default stream is the only way I have to stop this from happening, as apparently, anybody can create new modules freely. Sorry about that.
You do understand that what you will achieve that way is actually driving packagers away!!! I already orphaned eclipse packages in pristine and don't plan taking them back. Module is the only thing my team will support in Fedora if you say NO - so be it. Flatpak is the only thing that makes sense now IMHO considering the statements coming from Fedora .
I'm not blocking anything at this moment, as said, I'd like to hear the opinions of others as well.
I'm worried that by modularizing stuff we are already driving packagers away. So we are in a deep problem: modularizing more stuff drives packagers away, preventing modularization drives packagers away. I just try to find a way out of this spiral.
Allow modules and allow ursa major RIGHT NOW (tm). I don't see what's so difficult about that.
I don't have a magical allow ursa major RIGHT NOW button at my disposal, sorry.
To clarify: I am well aware that creating the default stream here is probably the only (doable) option at the moment. I'd just like to make sure it goes like this:
And not like this:
FWIW I saw this conversation on IRC:
[17:18:24] <mizdebsk> plarsen, try enabling eclipse module first [17:19:40] <plarsen> mizdebsk, hmmm - that works. But this means all the dnf group installs are a no-go? [17:20:15] <plarsen> I tried to install @robotics-suite - even @gnome-desktop-environment fails with missing dependencies or wrong obsolete references [17:20:52] <plarsen> Yeah, with eclipse:latest enables, @robotics-suite now installs
Because of this upgrade path problem (that could be fixed with adding a default stream for Eclipse) the robotics suite spin is moving away from Eclipse: https://pagure.io/fedora-comps/c/dd4afcfe619d395f9713693c8eea194033bff237
:-(
What prevents default stream for Eclipse to be added? Why hasn't it happened yet?
FESCo approval.
And well this happen? This bureaucracy is making me want to orphan all my fedora packages.
@akurtakov We need to figure that out.
@mbooth The main thing we need to know that hasn't come up in this thread (and sorry for not realizing it hadn't been asked yet): if we enable this as a default stream, would we expect this to break the buildroot or runtime environment of the non-modular packages?
Put another way: if these were non-modular packages, would we safely be able to include them in the buildroot/Everything repo or would they be replacing anything else?
If the answer to that is "no", then I'm +1 to granting this default stream status. If it's "yes", then we need to examine that further to see what can be done.
Metadata Update from @sgallagh: - Issue tagged with: meeting
@akurtakov It usually takes a week or two to approve a FESCo ticket. The FESCo members are human beings. If that makes you want to orphan all your Fedora packages, I don't know how to help you. If this is an urgent matter, please indicate why.
@akurtakov We need to figure that out. @mbooth The main thing we need to know that hasn't come up in this thread (and sorry for not realizing it hadn't been asked yet): if we enable this as a default stream, would we expect this to break the buildroot or runtime environment of the non-modular packages?
@sgallagh Quite the opposite, it would unbreak some things that are currently broken (see above).
You would safely be able to include them in the buildroot/Everything repo.
Based on https://pagure.io/fesco/issue/2236#comment-601166, I'm +1 to making this a default stream.
@akurtakov It usually takes a week or two to approve a FESCo ticket. The FESCo members are human beings. If that makes you want to orphan all your Fedora packages, I don't know how to help you.
Because this ticket was made a pointless rant against modularity. I don't care whether FESCo allows or disallows modularity but when you allow smth don't make it a way that cost others users and time lost. Thanks to @sgallagh for handling it proper - single question - is it breaking anything? -> no. -> go to voting. I guess this could have happened last week, right? Right after we cleaned up that our dependencies are in a module already. If there is something FESCo wants to chain with modularity - great success lies ahead if punishing packages whose dependencies are already in modules.
If it wasn't obvious https://pagure.io/fedora-comps/c/dd4afcfe619d395f9713693c8eea194033bff237 will make every maintainer mad as it hurts your user base due to bureaucracy.
If this is an urgent matter, please indicate why.
However, we've determined it is actually breaking things, haven't we? There are packages that BuildRequire eclipse packages. Ursa Major is not yet available. By moving to modules only you leave the maintainers of the dependent packages in void.
I guess this could have happened last week, right?
This happens when the human members of FESCo have time to vote.
BTW I'm +1 assuming that:
Until that happens, consider me -1. This is not a rant on modularity, this is a blocker that stops the domino.
BTW I'm +1 assuming that: all eclipse "ursine" packages are properly retired and not just left orphaned all other "ursine" packages are resolving runtime and buildtime dependencies on the removed packages properly or are retired (in coordination with their maintainers) as well Until that happens, consider me -1. This is not a rant on modularity, this is a blocker that stops the domino.
all eclipse "ursine" packages are properly retired and not just left orphaned all other "ursine" packages are resolving runtime and buildtime dependencies on the removed packages properly or are retired (in coordination with their maintainers) as well
So option like old eclipse.srpm version (and it's build-reqs stay as they are - not orphaned) rest is retired is a no-go? This way other ursine packages will keep compiling against the old eclipse for the time being - as both equinox osgi and swt have kept API stability for the last 10+ years I don't see an issue with that approach.
So option like old eclipse.srpm version (and it's build-reqs stay as they are - not orphaned) rest is retired is a no-go?
I'm lost. It was said that shipping the ursine eclipse package is not possible any more.
Well, no -- adding a default stream will not break those packages that currently have BR on eclipse -- if they build now (and they do build now) they will continue to build. I think it's unfair to penalise packagers based on the unavailability of ursa major -- I've waited as long as I could for ursa major and almost failed to ship Eclipse on Fedora as a consequence.
There is nothing currently broken downstream of Eclipse, since those packages require SWT only. The thing that is broken right now is the installation of the Eclipse IDE itself, and that will remain broken even if ursa major is introduced today -- this is the thing that will be fixed by the addition of a default stream.
As already suggested, for those packages that require SWT we can avoid retiring the ursine eclipse package that ships SWT until ursa major is ready, or package up SWT separately (which you previously sounded positive about in https://pagure.io/fesco/issue/2236#comment-600325 -- any reason you change your mind on this point?)
package up SWT separately (which you previously sounded positive about in https://pagure.io/fesco/issue/2236#comment-600325 -- any reason you change your mind on this point?)
I am still positive about this plan. Sorry if it sounded like I'm not. This is a good plan.
What I'm negative about is keeping uninstallable orphaned/broken packages in the ursine repos and "shadowing" them via default modular streams. Hence I'd outlined the requirements in https://pagure.io/fesco/issue/2236#comment-601183 - shipping standalone SWT sounds like it solves them.
package up SWT separately (which you previously sounded positive about in https://pagure.io/fesco/issue/2236#comment-600325 -- any reason you change your mind on this point?) I am still positive about this plan. Sorry if it sounded like I'm not. This is a good plan. What I'm negative about is keeping uninstallable orphaned/broken packages in the ursine repos and "shadowing" them via default modular streams. Hence I'd outlined the requirements in https://pagure.io/fesco/issue/2236#comment-601183 - shipping standalone SWT sounds like it solves them.
I am still positive about this plan. Sorry if it sounded like I'm not. This is a good plan. What I'm negative about is keeping uninstallable orphaned/broken packages in the ursine repos and "shadowing" them via default modular streams. Hence I'd outlined the requirements in https://pagure.io/fesco/issue/2236#comment-601183 - shipping standalone SWT sounds like it solves them.
Okay good, then we are on the same page :-)
Note that in https://pagure.io/fesco/issue/2236#comment-600239 I've only outlined the subpackages of the eclipse package. But I suppose there are more packages that this module is going replace. Do we have a list of binary packages? I've tried with repoquery --repo=rawhide-modular | grep eclipse, but it yields nothing.
repoquery --repo=rawhide-modular | grep eclipse
Here is a quick list of binary eclipse packages in the module so far:
https://paste.fedoraproject.org/paste/3JAGM4JmKdwNByztT9-eog
I've also tried this and it failed:
$ sudo dnf module install eclipse:latest Last metadata expiration check: 0:33:10 ago on Mon Sep 30 16:19:13 2019. Error: Problems in request: broken groups or modules: eclipse:latest Modular dependency problems: Problem: conflicting requests - module eclipse:latest:3020190920120950:936e8d48-0.x86_64 requires module(ant:1.10), but none of the providers can be installed - module ant:1.10:2820190409091957:819b5873-0.x86_64 is disabled - module ant:1.10:2820190508055149:819b5873-0.x86_64 is disabled
My default profile PR was only merged today, so you may need to specify one until that percolates through, e.g.:
sudo dnf module install eclipse:latest/java
Edit: Also it obviously will not install if you have explicitly disable the ant module, which is a runtime dependency ;-) You can read about how to resolve this situation on my blog: http://blog.matbooth.co.uk/10-eclipse-module-f30-addendum.html
Also it obviously will not install if you have explicitly disable the ant module
I don't recall doing anything with the ant module, but I cannot rule it out. Most of my modular enablements or disablement are done by the dnf magic tricks. Also, dnf doesn't tell me that I have disabled the ant module, so the error is not actionable. But I realize that this is not the eclipse module fault :(
Anyway, here is a naive attempt to list impacted packages:
$ for pkg in $pkgs; do echo "## $pkg"; repoquery --repo=koji --whatrequires $pkg 2>/dev/null | pkgname | sort | uniq | egrep -v "^$(echo $pkgs | tr ' ' '|')$" ; echo; done ## eclipse-abrt ## eclipse-cdt eclipse-avr eclipse-photran eclipse-photran-intel eclipse-photran-xlf eclipse-ptp eclipse-ptp-etfw-tau eclipse-ptp-etfw-tau-fortran eclipse-ptp-pldt-fortran eclipse-ptp-pldt-upc eclipse-ptp-rdt-sync-fortran eclipse-sgx ## eclipse-cdt-arduino ## eclipse-cdt-docker ## eclipse-cdt-llvm ## eclipse-cdt-native eclipse-avr eclipse-photran eclipse-photran-intel eclipse-photran-xlf eclipse-ptp eclipse-ptp-etfw-tau eclipse-ptp-gem eclipse-ptp-pldt-fortran eclipse-ptp-pldt-upc eclipse-ptp-rdt-sync-fortran eclipse-sgx ## eclipse-cdt-qt ## eclipse-cdt-sdk ## eclipse-dtp ## eclipse-ecf-core ## eclipse-ecf-runtime ## eclipse-ecf-sdk ## eclipse-egit eclipse-contributor-tools eclipse-tests ## eclipse-egit-github ## eclipse-egit-mylyn ## eclipse-emf-core ## eclipse-emf-runtime eclipse-contributor-tools eclipse-dltk-tcl ## eclipse-emf-sdk ## eclipse-emf-xsd ## eclipse-epp-logging ## eclipse-equinox-osgi hibernate-osgi ## eclipse-gef eclipse-pdt ## eclipse-gef-sdk ## eclipse-jdt eclipse-anyedit eclipse-contributor-tools eclipse-eclemma eclipse-findbugs eclipse-checkstyle eclipse-moreunit eclipse-m2e-mavendev eclipse-m2e-plexus eclipse-m2e-takari eclipse-tests ## eclipse-jgit eclipse-contributor-tools eclipse-ptp eclipse-tests ## eclipse-launchbar ## eclipse-linuxtools ## eclipse-linuxtools-changelog ## eclipse-linuxtools-docker ## eclipse-linuxtools-gcov ## eclipse-linuxtools-gprof ## eclipse-linuxtools-javadocs ## eclipse-linuxtools-libhover ## eclipse-linuxtools-manpage eclipse-dltk-sh ## eclipse-linuxtools-perf ## eclipse-linuxtools-rpm-editor ## eclipse-linuxtools-systemtap ## eclipse-linuxtools-vagrant ## eclipse-linuxtools-valgrind ## eclipse-m2e-apt ## eclipse-m2e-buildhelper ## eclipse-m2e-core eclipse-m2e-antlr eclipse-m2e-cxf eclipse-m2e-maven-dependency-plugin eclipse-m2e-mavendev eclipse-m2e-modello eclipse-m2e-plexus eclipse-m2e-sisu eclipse-m2e-takari ## eclipse-m2e-core-javadoc ## eclipse-m2e-core-tests ## eclipse-m2e-egit ## eclipse-m2e-mavenarchiver ## eclipse-m2e-tycho ## eclipse-m2e-workspace eclipse-m2e-mavendev ## eclipse-m2e-workspace-javadoc ## eclipse-m2e-wtp ## eclipse-mpc ## eclipse-mylyn eclipse-dltk-mylyn eclipse-pdt ## eclipse-mylyn-builds ## eclipse-mylyn-builds-hudson ## eclipse-mylyn-context-cdt ## eclipse-mylyn-context-java ## eclipse-mylyn-context-pde ## eclipse-mylyn-docs-wikitext ## eclipse-mylyn-sdk ## eclipse-mylyn-tasks-bugzilla ## eclipse-mylyn-tasks-trac ## eclipse-mylyn-versions ## eclipse-mylyn-versions-cvs ## eclipse-mylyn-versions-git ## eclipse-mylyn-versions-subclipse ## eclipse-p2-discovery eclipse-pdt eclipse-tests ## eclipse-pde eclipse-contributor-tools eclipse-dltk-sdk eclipse-pdt-sdk eclipse-tests ## eclipse-platform eclipse-color-theme eclipse-contributor-tools eclipse-dltk eclipse-epic eclipse-packagekit eclipse-quickrex jacoco swt-chart tycho ## eclipse-pydev ## eclipse-pydev-mylyn ## eclipse-remote eclipse-ptp eclipse-ptp-etfw-tau eclipse-ptp-gem ## eclipse-subclipse ## eclipse-swt azureus jfreechart-swt tuxguitar ## eclipse-testng ## eclipse-tm-terminal eclipse-pdt eclipse-ptp ## eclipse-tm-terminal-connectors eclipse-pdt eclipse-ptp ## eclipse-tm-terminal-sdk ## eclipse-usage ## eclipse-webtools-common eclipse-pdt ## eclipse-webtools-dali ## eclipse-webtools-javaee ## eclipse-webtools-servertools eclipse-pdt ## eclipse-webtools-sourceediting eclipse-pdt $ for pkg in $pkgs; do echo "## $pkg"; repoquery --repo=koji-source --whatrequires $pkg 2>/dev/null | pkgname | sort | uniq | egrep -v "^$(echo $pkgs | tr ' ' '|')$" ; echo; done ## eclipse-abrt ## eclipse-cdt eclipse-avr eclipse-photran eclipse-sgx ## eclipse-cdt-arduino ## eclipse-cdt-docker ## eclipse-cdt-llvm ## eclipse-cdt-native ## eclipse-cdt-qt ## eclipse-cdt-sdk ## eclipse-dtp eclipse-webtools ## eclipse-ecf-core eclipse ## eclipse-ecf-runtime ## eclipse-ecf-sdk ## eclipse-egit eclipse ## eclipse-egit-github ## eclipse-egit-mylyn ## eclipse-emf-core eclipse ## eclipse-emf-runtime eclipse eclipse-dltk eclipse-ecf eclipse-webtools ## eclipse-emf-sdk ## eclipse-emf-xsd ## eclipse-epp-logging ## eclipse-equinox-osgi ## eclipse-gef eclipse-webtools ## eclipse-gef-sdk ## eclipse-jdt eclipse-anyedit eclipse-checkstyle eclipse-webtools ## eclipse-jgit eclipse-ptp ## eclipse-launchbar eclipse-photran ## eclipse-linuxtools ## eclipse-linuxtools-changelog ## eclipse-linuxtools-docker ## eclipse-linuxtools-gcov ## eclipse-linuxtools-gprof ## eclipse-linuxtools-javadocs ## eclipse-linuxtools-libhover ## eclipse-linuxtools-manpage ## eclipse-linuxtools-perf ## eclipse-linuxtools-rpm-editor ## eclipse-linuxtools-systemtap ## eclipse-linuxtools-vagrant ## eclipse-linuxtools-valgrind ## eclipse-m2e-apt ## eclipse-m2e-buildhelper ## eclipse-m2e-core ## eclipse-m2e-core-javadoc ## eclipse-m2e-core-tests ## eclipse-m2e-egit ## eclipse-m2e-mavenarchiver ## eclipse-m2e-tycho ## eclipse-m2e-workspace ## eclipse-m2e-workspace-javadoc ## eclipse-m2e-wtp ## eclipse-mpc ## eclipse-mylyn eclipse-dltk ## eclipse-mylyn-builds ## eclipse-mylyn-builds-hudson ## eclipse-mylyn-context-cdt ## eclipse-mylyn-context-java ## eclipse-mylyn-context-pde ## eclipse-mylyn-docs-wikitext ## eclipse-mylyn-sdk eclipse-pdt ## eclipse-mylyn-tasks-bugzilla ## eclipse-mylyn-tasks-trac ## eclipse-mylyn-versions ## eclipse-mylyn-versions-cvs ## eclipse-mylyn-versions-git ## eclipse-mylyn-versions-subclipse ## eclipse-p2-discovery eclipse-pdt ## eclipse-pde eclipse eclipse-color-theme eclipse-dltk eclipse-ecf eclipse-eclemma eclipse-emf eclipse-findbugs eclipse-moreunit eclipse-pdt eclipse-ptp eclipse-webtools ## eclipse-platform maven-eclipse-plugin tycho ## eclipse-pydev ## eclipse-pydev-mylyn ## eclipse-remote eclipse-ptp ## eclipse-subclipse ## eclipse-swt azureus jfreechart jogl2 tuxguitar ## eclipse-testng ## eclipse-tm-terminal eclipse-ptp ## eclipse-tm-terminal-connectors eclipse-pdt eclipse-ptp ## eclipse-tm-terminal-sdk ## eclipse-usage ## eclipse-webtools-common ## eclipse-webtools-dali ## eclipse-webtools-javaee ## eclipse-webtools-servertools ## eclipse-webtools-sourceediting eclipse-pdt
Assuming all the eclipse- packages get retired from regular Fedora, this is what remains:
eclipse-
## eclipse-equinox-osgi datanucleus-core hibernate hibernate-osgi ## eclipse-platform jacoco maven-eclipse-plugin swt-chart tycho ## eclipse-swt azureus jfreechart jfreechart-swt jogl2 tuxguitar
Assuming all the eclipse- packages get retired from regular Fedora, this is what remains: ## eclipse-equinox-osgi datanucleus-core hibernate hibernate-osgi Should be easily covered by felix-* or eclipse-equinox-osgi standalone like swt if decided. ## eclipse-platform jacoco
Assuming all the eclipse- packages get retired from regular Fedora, this is what remains: ## eclipse-equinox-osgi datanucleus-core hibernate hibernate-osgi Should be easily covered by felix-* or eclipse-equinox-osgi standalone like swt if decided.
## eclipse-platform jacoco
A dep of eclipse-eclemma.
maven-eclipse-plugin Dead package for long time. swt-chart Dep of eclipse-linuxtools. tycho Used only to build eclipse packages.
maven-eclipse-plugin Dead package for long time.
swt-chart Dep of eclipse-linuxtools.
tycho Used only to build eclipse packages.
These are all deps of other eclipse packages so
## eclipse-swt azureus jfreechart jfreechart-swt jogl2 tuxguitar
Agreed in the meeting:
I think Fedora urgently needs to implement @churchyard's proposal (from the mailing list) to ban module-only packages, requiring the default version to be maintained as part of the distribution rather than as a default stream, and in particular also requiring modules to have a default version to begin with.
Moving more and more packages to module-only as proposed here is only going to make the problem worse.
Agreed in the meeting: have a bug filed and propose it as a blocker for the release figure out details in the bugreport, especially the double ownership get fesco to vote again on resolution (+5, 0, -0)
have a bug filed and propose it as a blocker for the release figure out details in the bugreport, especially the double ownership get fesco to vote again on resolution (+5, 0, -0)
See: https://bugzilla.redhat.com/show_bug.cgi?id=1759176
This was discussed during today's fesco meeting:
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Sigh… This is completely backwards.
@kkofler You are not ignored. But this is the only available workaround for F31, given by the release schedule.
Let's focus on F32 now.
This is not the only available workaround.
I guess we are blocked by bureaucracy: https://pagure.io/releng/issue/8877
And https://pagure.io/releng/issue/8883
Login to comment on this ticket.