Bug#790816: RFS: roxterm/3.0.1-1
On Fri, Jul 3, 2015 at 8:30 AM, Tony Houghton <h@realh.co.uk> wrote:
>> - 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?
Not that I know of...I've never really worried about supporting
parallel builds in my own packages, to be honest.
>> 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?
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.
>> - 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).
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).
Regards,
Vincent
Reply to: