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

Re: Solving lintian warnings for multi-package roxterm



On Thu, 18 Aug 2011 10:41:33 +0200
David Kalnischkies <kalnischkies@gmail.com> wrote:

> On Thu, Aug 18, 2011 at 01:39, Tony Houghton <h@realh.co.uk> wrote:
> > package too, eg to roxterm-gtk3. In the latter case would adding
> > "Replaces: roxterm" cause it to automatically replace roxterm at
> > apt-get upgrade (or only dist-upgrade?) or would I have to make a
> > meta-package?
> 
> No. 'Replaces: A' is just a hint for dpkg that some (or _maybe_ all)
> files of package A are replaced with files from your package.
> (d-policy §7.6 [0]) Especially, this doesn't say anything about the
> functionality!
> 
> Some hints on how to correctly rename a package can be found in the
> wiki [1].

I'd rather keep the name "roxterm" for the GTK3 version if that's OK. I
don't really want the main package to be named after a library
dependency and have to relegate "roxterm" to a dummy package.

> Bonus: With my APT hat on i want to add that i will beat the hell out
> of you if you try to remove the old package with an unversioned
> Breaks/Conflicts. That is a dist-upgrade nightmare as it does what
> the maintainer intended only in a subset of situations and in all
> others the opposite will happen (= no upgrade) - and before someone
> adds Provides to the list: Remember that dependencies on Provides
> need to be unversioned.

Don't worry, I can easily see that abusing Conflicts like that would be
stupid :-).

> Oh, and regarding the name as is: What does upstream intend:
> Do they treat gtk2 as legacy and will remove support in the long-run
> or do they want to support it for… lets say 2 years at least?

I am upstream. I don't plan to drop gtk2 support soon, especially not
before #632403 is resolved or I find a satisfactory workaround. But
eventually I suppose gtk2 will be very much a legacy thing and only be
used by poorly maintained packages (I can imagine that being at least 2
years away though) and then it will be advantageous to remove a lot of
#if... blocks and configure checks - not just for GTK2 vs 3 but for
features that only became available midway through gtk2's and vte's
lives.


Reply to: