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

Bug#988188: marked as done (Ignoring but #987904 for Bullseye: horizon plugin packaging design mistake)

Your message dated Thu, 1 Jul 2021 13:52:32 +0200
with message-id <6b34bf21-ed0e-b23e-4fcd-77afa13b6b49@debian.org>
and subject line Follow-up on bug #990530 (was: Ignoring but #987904 for Bullseye: horizon plugin packaging design mistake)
has caused the Debian Bug report #988188,
regarding Ignoring but #987904 for Bullseye: horizon plugin packaging design mistake
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
988188: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988188
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal

Hi,

I need to discuss with the release team what to do in order to address
this bug: https://bugs.debian.org/987904

What happens is that each Horizon plugin is installing a bunch of python
files under /etc/openstack-dashboard/enable.

When an Horizon plugin is removed, as the enable folder is in /etc, the
enable files of the plugins aren't removed. As a consequence, whenever
Horizon attemps to list its plugins (for example, when it tries to do a
"collect static" operation, which is kind of compiling all the JS files
into a single one, each time a plugin is added/removed or when Horizon
upgrades), it just fails, because the files in the enable folder are
referencing Python modules that do not exist anymore (since the plugin
package has been removed).

The solution to fix this is strait forward: replace our symlink in
/usr/lib/python3/dist-packages/openstack_dashboard/enable by a folder,
and push the enable files in there instead of /etc. This way, the plugins
removal will also remove the enable files.

The problem is that there are 20 Horizon plugins in Debian, and at this
point in the release cycle, it doesn't feel like it is a good time to
update 20 packages.

So in my point of view, what we can do now is:
- tag #987904 as bullseye-ignore
- add a warning in the release notes that Horizon plugins should never
be just removed, but should be *purged*, to avoid the problem

In the mean while, I'll fix the Horizon packaging in Experimental, and
see how it goes.

Dear release team, please let share your view on this bug.
I remain available if you need more explanations.

Cheers,

Thomas Goirand (zigo)

--- End Message ---
--- Begin Message --- 
Hi,

As per Sebastian reply, I have uploaded Horizon and all of its plugins
to fix #987904 (with the enable files of plugins staying in /etc after a
package removal (ie: with package not purged), refering to non-existent
plugin code, leading to horizon's manage.py to fail in maintainer scripts).

So sanity should be restored, with the enable files now stored under
/usr, as it should have been to begin with.

Please note that I have opened a (more normal) bug for unblocking
Horizon and all of its plugins. I'm therefore hereby closing this bug.
Please follow-up on that unblock bug:

https://bugs.debian.org/990530

Cheers,

Thomas Goirand (zigo)

--- End Message ---
Reply to: