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

Bug#790816: RFS: roxterm/3.0.1-1



On 04/07/15 10:19, Vincent Cheng wrote:
On Fri, Jul 3, 2015 at 8:30 AM, Tony Houghton <h@realh.co.uk> wrote:

My thinking is that anybody still using roxterm-gtk2 has some good
reason to do so and will not want to upgrade to a GTK3 version even if
it means missing out on the latest features and bug fixes; they are
already missing out on some useful features from vte-2.90. With the
relationships the way they are at the moment users can keep roxterm-gtk2
without having to pin it. I tested that scenario and it seems to work.
But, since vte9 (the GTK2 version of vte) is scheduled for removal from
the archive, is this undesirable?

Ah, I didn't realize that this is actually intentional. Well, IMHO
it's saner to offer users an upgrade path by default (i.e. to the gtk3
version), and let them choose to manually pin packages if they don't
want to upgrade for some reason. However, I can't find a Policy
reference that mandates all binary packages to have an upgrade path or
similar, so I'll leave the choice to you.

I think I'll change my decision on that. There do seem to be stronger
reasons for providing an automatic upgrade from roxterm-gtk2 than to
make things easier for users who want to keep it without continued
support and maintenance.

Ack, roxterm should declare Breaks: roxterm-gtk2 (in addition to
-gtk3) and roxterm-dbg should declare Breaks: roxterm-gtk2-dbg (in
addition to -gtk3-dbg). Why wouldn't you want the equivalent Replaces
relationships here as well? Having roxterm declare Replaces:
roxterm-gtk2 is not going to force roxterm-gtk2 to be automatically
upgraded in the first scenario I described in my last email (where the
user has roxterm-gtk2 and roxterm-common installed, but not roxterm;
nothing gets upgraded in this scenario). Without Replaces, users who
currently have only roxterm-gtk2 and roxterm-common installed, who
then decide to switch to the gtk3 version by running apt-get install
roxterm, can't do so (at least, not without removing roxterm-gtk2
first).

One other point I noticed is that currently I have roxterm-data Breaks
and Replaces roxterm << 3.0.0-1 (actually I put 2 instead of 3 by
mistake so that needs changing anyway), where roxterm << 3 is the old
virtual package. As there is no direct replacement for that, do you
agree I should keep the Breaks where it is but remove the Replaces?
Breaks probably isn't strictly necessary either, but it might be a good
idea just in case there's a clash in /usr/share/doc/roxterm.


Reply to: