Bug#790816: RFS: roxterm/3.0.1-1
On 02/07/15 21:09, Vincent Cheng wrote:
Control: tag -1 + moreinfo
Control: owner -1 !
Hi Tony,
On Wed, Jul 1, 2015 at 1:22 PM, Tony Houghton <h@realh.co.uk> wrote:
I thought I had released 2.9.6-1 and 2.9.7-1 via sponsorship too, but
for some reason the current version in unstable is still 2.9.5-1. Is the
changelog OK as above or should I merge these entries?
Please merge the above d/changelog entries.
Done. I think I've realised/remembered the reason for the "missing"
releases. I released them upstream and in my Ubuntu PPA, but not for
Debian because it was in freeze at the time and I didn't think the
changes were important enough for an unblock.
I just skimmed the debdiff between 2.9.5-1 and your package on mentors
and noticed a few small things:
- your newly added d/copyright stanza for ".ycm_extra_conf.py.in" has
a License: GPL-3+ header, but the license body references GPL-2
multiple times.
Fixed. But I have some more questions before I upload a new version...
- d/rules: CFLAGS = $(shell dpkg-buildflags | grep '^CFLAGS=') is
quite brittle; I suggest using dpkg-buildflags --get CFLAGS instead
(ditto for CPPFLAGS and LDFLAGS)
That's better, I don't know how I missed that, unless it's a recent
addition to dpkg-buildflags. The way I get the parallel option looks
quite nasty too, is there a better way to do that?
Regarding your package split, have you tested other possible upgrade
scenarios? There's a few scenarios I can think of that are broken or
not ideal:
- A user who just has roxterm-gtk2 installed (and roxterm-common
auto-installed), without the roxterm metapackage, will not get any
updates because both of these packages are no longer built from
src:roxterm
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?
- A user has roxterm-gtk2 and roxterm-gtk2-dbg installed. Aside from
the same problem as the first scenario, if he/she now chooses to
apt-get install roxterm-dbg, (I think) dpkg will explode due to file
conflicts between roxterm-gtk2-dbg and roxterm-dbg.
So I should add Breaks: roxterm-gtk2-dbg to roxterm-dbg, and I think it
would also be more appropriate to move Breaks: roxterm-gtk2 and
roxterm-gtk3 from roxterm-data to roxterm, because the latter is the
package that contains the corresponding files. But, if the previous
point about preventing roxterm-gtk2 from being automatically upgraded is
OK, I don't want to add Replaces: roxterm-gtk2(-dbg).
Reply to: