Re: Restructuring roxterm packaging (was Replacing roxterm's multiple binary packages with one)
On Sun, Jun 14, 2015 at 5:44 AM, Tony Houghton <h@realh.co.uk> wrote:
> On 09/06/15 14:04, Dominique Dumont wrote:
>>
>> On Monday 08 June 2015 16:54:53 Tony Houghton wrote:
>>>
>>> roxterm-common (data files, roxterm-gtk2 and roxterm-gtk3 depend on it)
>>> roxterm-gtk2, roxterm-gtk3 (binaries)
>>> roxterm-gtk2-dbg, roxterm-gtk3-dbg (corresponding debugging symbols)
>>> roxterm (virtual package depending on roxterm-gtk3)
>>>
>>> I want to replace them with a single package, "roxterm". I'm not quite
>>> sure how to set up the package relationships to do this. I would like
>>> the new roxterm to automatically replace roxterm-gtk3, so I think I need
>>> to add Replaces: roxterm-gtk3 to the new roxterm, and AFAICT from the
>>> policy manual I should use Breaks as well (rather than Conflicts).
>>
>>
>> Depending on its size, it may be better to keep roxterm-common: this
>> package
>> is arch:all and this would avoid duplication these data for each arch.
>>
>> Next, you may want to consider what will happen if (or when?) gtk4 appears
>> on
>> your radar screen: will you split roxterm package again ?
>
>
> OK, I'll keep the current structure, apart from dropping the gtk2 packages.
> However, now that there isn't more than one supported GTK version the names
> aren't so appropriate. I'd like to rename roxterm-common to roxterm-data,
> drop the virtual package and rename roxterm-gtk3 to just "roxterm"
> (similarly roxterm-gtk3-dbg -> roxterm-dbg). Should I avoid those changes
> unless absolutely necessary, or go ahead and make them now? "roxterm-gtk3"
> would presumably have to be renamed eventually anyway on migration to GTK4.
If these changes are inevitable, it's really up to you as to when you
want to make them happen (I'd suggest that doing them early in the
release cycle is better than later, however). I think these changes
sound fine in principle, although a debdiff would certainly make it
easier to make a judgment. Either way, please be sure to test various
upgrade scenarios with piuparts and/or manually using a chroot/VM
before uploading your package!
Regards,
Vincent
Reply to: