Hi Steve,
(it's a long message, the important bits are just at the bottom).
2017-04-01 20:48 Steve Langasek:
Hi Manuel,
In May 2015, you wrote:
I plan to ask FTP-masters for removal from unstable in a few months, when
the new desktop is usable.
But then in December 2016, you wrote:
I am not sure, is there a big compelling reason to remove it, like big
security bugs? It's dead upstream but it's still working fine without
maintainance, and building in all Linux-based architectures.
You didn't quote the following paragraphs in that message, which I think
that are relevant:
"I thought that once removed from unstable and LXQt becoming ready, it
would decline in popularity measurably so we could think about
removing it... but it's not declining, even as % it's maintaining the
same levels [...]
Once it disappears from the next stable maybe people migrate to LXQt
and we see a big drop, or maybe complain that it was removed from
stable or something... but until then, since there seem to be users, I
don't have any compelling reason to remove it."
Will come back to this later...
I don't know if you find it compelling, but you have agreed that this
package should not be in the next Debian release, which is why it's removed
from testing; but by leaving it in unstable, it may still be included in
releases of derivative distributions that pull from unstable. Ubuntu is an
example of this - and for Ubuntu, we will manually remove the package - but
other distributions may also be affected.
You mention popcon as a reason for not removing the package. I guess there
are a lot of users who have the package installed because it was a
dependency of something else in the archive, and it's still installed
because there was no transition which forced it off their systems. I
wouldn't read into a high popcon count for a non-leaf package.
Some (gentle) popcon saber-rattling:
"razorqt-desktop" is not a leaf package, but "razorqt" is, only other
"razorqt-*" packages Suggest it. (That's enough to keep it installed
once it's been installed in most systems by default, I think, but
still).
"razorqt" is currently at 157, while it peaked at ~230 or so, and it's
at the same level or higher than in mid 2015 (the big GCC-5 / C++11 ABI
change):
https://qa.debian.org/popcon-graph.php?packages=razorqt&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1
In percentages it's more clear that there're less installations than in
the past:
https://qa.debian.org/popcon-graph.php?packages=razorqt&show_installed=on&want_percent=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
This is similar for all packages in this collection (the graph is oddly
flattish):
https://qa.debian.org/popcon-graph.php?packages=razorqt+libqtxdg0+libqtxdg0-dev+librazorqt0+librazorqt0-dev+razorqt-data+razorqt-appswitcher+razorqt-autosuspend+razorqt-config+razorqt-confupdate+razorqt-desktop+razorqt-globalkeyshortcuts+razorqt-lightdm-greeter+razorqt-notificationd+razorqt-openssh-askpass+razorqt-panel+razorqt-policykit-agent+razorqt-power+razorqt-runner+razorqt-session&show_installed=on&want_percent=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
Anyway, "razorqt-desktop" is a non-leaf packages, but only "razorqt"
Depends on it, and only other "razorqt-*" packages Recommend it.
AFAIK it's been always like this in the past, there were no external
reverse dependencies outside this group of packages.
So in light of this, since the dependencies are (and AFAIK always were
only) among razorqt packages, I think that it's reasonable to assume
that people have installed it on purpose (not pulled by other packages),
and there are people using it recently ("vote" columns).
I am glad that LXQt is in Debian now, and I would be happy to remove it
if the numbers dropped dramatically (that's what I thought that it would
happen when I wrote the message back in 2015). But as things stand,
there are still more than half the installations reported than at peak
times, so I would just feel bad removing it from the archive at this
point.
Since the release is only weeks/months away, I would like to wait and
see what happens.
Is there another way to avoid this problem for derivatives, while
maintaining it in unstable?
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
