#6836 Retire all packages with broken deps
Closed: Can't Fix 6 years ago Opened 6 years ago by kalev.

As per https://fedorapeople.org/groups/schedule/f-26/f-26-releng-tasks.html , could someone please send out weekly notifications to package maintainers that packages with broken deps are going to get retired, and then retire them before the Final freeze?

We missed this process for F25 so there's a few more broken deps than usual.


I will take care of this.

Metadata Update from @till:
- Issue assigned to till

6 years ago

On the last meeting we decided to block all unfixed pkgs in f26-compose and give maintainers 6 more weeks to fix the packages: https://meetbot.fedoraproject.org/teams/releng/releng.2017-06-26-14.33.html

I blocked today all the packages no other package depends on:

OmegaT RackTables Ray YafaRay atomicapp ayttm banshee-community-extensions beacon buildah calligra compat-gcc-34 dnsperf eclipse-avr elemental fedora-dockerfiles floppy-support fusionforge gcc-python-plugin gif2png git-annex gofed golang-github-docker-go-connections golang-github-docker-libcontainer golang-github-kubernetes-heapster golang-github-samalba-dockerclient grass gyachi homerun java-gnome kf5-libkface ledger meshlab mesos mnemosyne modularity-testing-framework nik4 nodejs-file-entry-cache ocid origin osm2pgsql php-magickwand php-pecl-parsekit php-pecl-runkit prelude-correlator prewikka pyrasite python-django-admin-honeypot python-hardware python-keystonemiddleware python-oslo-versionedobjects python-rhev qutim rOCCI-server rootplot rpm-ostree-toolbox rubygem-kgio shutter sinfo source-to-image sslogger system-config-kickstart valabind vdsm vifir vim-syntastic xastir ytnef

Some of them are already fixed in testing and they were approved as a FE. They need to be unblocked when they get pushed.

Unblocked

atomicapp modularity-testing-framework fedora-dockerfiles java-gnome rpm-ostree-toolbox gofed

because of https://pagure.io/releng/issue/6870

I blocked the remaining offenders (packages other packages depend on and the packages depending on them):
asterisk consul erlang-riak_pipe gearmand golang-github-fsouza-go-dockerclient golang-github-gonum-matrix golang-github-mistifyio-go-zfs golang-googlecode-go-exp nodejs-connect python-ironicclient python-oslo-middleware qgis asterisk-gui asterisk-sounds-core cadvisor custodia erlang-riak_kv erlang-riak_search golang-github-docker-libkv golang-github-gonum-graph golang-github-prometheus-prometheus nodejs-express nodejs-grunt-contrib-connect php-pecl-gearman python-oslo-messaging python-shade source-to-image

It would be great to also fix asterisk but this might require also to rebuild some other pkgs to change the dependencies to the openssl compat pkgs insteal of openssl-devel. One remaining broken dep should be fixed once https://bugzilla.redhat.com/show_bug.cgi?id=1466957 is fixed.

There are also some more pkgs that could be fixed with a FE but I did not yet get to it (floppy-support and vim-syntastic at least).

Oh jeez. It is absolutely unacceptable that this kind of monkeying about with the package list should be happening during Final freeze, with no interface at all with the release blocker / FE process and the compose process. This absolutely needed to be done well in advance of the Final freeze. The entire point of the release freezes is to allow us to build composes with some confidence about what goes into them (and confidence that there will not be unexpected changes between composes during freezes, only the changes we have very specifically decided we will include).

Please don't ever do this kind of thing during a milestone freeze again.

We discussed this matter at the blocker review meeting of 2017-07-03. We agreed the following:

"The blocking of packages with dependency problems - https://pagure.io/releng/issue/6836 - was done far too late (well into Final freeze) and has already caused the RC-1.3 compose to be a failure. We agreed that all the packages blocked as part of that ticket should be unblocked again, and this kind of blocking should never be done without going through the FE/blocker process in future."

Accordingly, please unblock all the packages that were blocked (see lists above) before composing RC-1.4. Thanks!

Do I understand correctly that we will not remove pkgs with broken deps for Fedora 26? I will then write a notification to the devel list.

Do I understand correctly that we will not remove pkgs with broken deps for Fedora 26? I will then write a notification to the devel list.

Is this something we should do on branched, or should we periodically cull them from rawhide after some period of brokenness?

If branched, should we make it something that's either part of the branching standard operating procedure itself, or written into the schedule? (Maybe put it in on the same day as Bodhi activation? https://fedoraproject.org/wiki/Releases/27/Schedule)

Is this something we should do on branched, or should we periodically cull them from rawhide after some period of brokenness?
If branched, should we make it something that's either part of the branching standard operating procedure itself, or written into the schedule?

I filed a separate issue about refining the cleanup process in #6877 - I guess this all depends on how much brokenness we would like to tolerate in the final release.

@till "Do I understand correctly that we will not remove pkgs with broken deps for Fedora 26?"

Yes, that's what we decided, to ensure no more cases like custodia would crop up; our testing cannot catch everything, especially in short time.

I just wrote the e-mail. AFAICS there is nothing that can be done here.

Metadata Update from @till:
- Issue close_status updated to: Can't Fix
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata