Re: Solving lintian warnings for multi-package roxterm
On Fri, Aug 19, 2011 at 00:58, Russ Allbery r...@debian.org wrote:
David Kalnischkies kalnischk...@gmail.com writes:
Sidenote: I am not sure why the usage of 'disappearing packages' was
removed from the wiki as dpkg and APT support them in squeeze - at least
in my eyes it looked like the holy grail to prevent maintainers from
using all these half-working tricks in battle against APT, but i will
leave that up to decide for others as IANAD{D,M}.
You can't use disappearing packages with Policy-compliant packages so far
as I can tell, since it would require both packages provide the same
/usr/share/doc directory and changelog file, which is a Policy violation.
oldpkg depends on newpkg - and in terms of a package rename it should be
coming from the same source package.
/usr/share/doc/oldpkg is a link to /usr/share/doc/newpkg in both, the oldpkg
and the newpkg, so that new- can take over the last remaining file of oldpkg.
Isn't that exactly what §12.5 allows?
Quoting: http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
/usr/share/doc/package may be a symbolic link to another directory
in /usr/share/doc only if the two packages both come from the same source
and the first package Depends on the second. These rules are important
because copyrights must be extractable by mechanical means.
The usr-share-doc-symlink-to-foreign-package tag in lintian also only triggers
if the packages are not from the same source package.
So is there another section in conflict with this one or
have i just misunderstood something?
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAZ6_fAQ=RYy9rHKVrB3OTwHxKU7v_0dOptRE7PSLof+^e...@mail.gmail.com
Re: Solving lintian warnings for multi-package roxterm
On Thu, 18 Aug 2011 13:51:11 +0100 Tony Houghton h...@realh.co.uk wrote: On Thu, 18 Aug 2011 10:41:33 +0200 David Kalnischkies kalnischk...@gmail.com wrote: [Snip] 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. I think perhaps I'd better use a dummy package after all, because the GTK3 and GTK2 versions should Conflict with each other, and having one of them with the same name as the old package makes that a bit awkward and I'd be in danger of being beaten up by David :-). 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. http://wiki.debian.org/Renaming_a_Package says that where one of the new packages Provides the old name it isn't enough for apt to automatically find the correct package to upgrade to (and I can see that if more than one provides it, as would be the case with roxterm, it would be impossible to choose automatically). If the dummy roxterm has: Depends: roxterm-gtk3 | roxterm-gtk2 (plus versions) will that make apt automatically pick roxterm-gtk3 or would I have to make it roxterm-gtk3 only and roxterm-gtk2 users have to uninstall the dummy package? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110819134235.53b32aef@junior
Re: Solving lintian warnings for multi-package roxterm
David Kalnischkies kalnischk...@gmail.com writes: On Fri, Aug 19, 2011 at 00:58, Russ Allbery r...@debian.org wrote: You can't use disappearing packages with Policy-compliant packages so far as I can tell, since it would require both packages provide the same /usr/share/doc directory and changelog file, which is a Policy violation. oldpkg depends on newpkg - and in terms of a package rename it should be coming from the same source package. /usr/share/doc/oldpkg is a link to /usr/share/doc/newpkg in both, the oldpkg and the newpkg, so that new- can take over the last remaining file of oldpkg. Isn't that exactly what §12.5 allows? Yes, but 12.5 is wrong in implying this is always permitted, because such packages do not provide a valid changelog in all situations. It only works if both packages are arch: all and have a specific versioned dependency (with =). At that point, you've narrowed the usability so much that I'm not sure there's any point in pursuing this technique. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxf5c8xu@windlord.stanford.edu
Re: Solving lintian warnings for multi-package roxterm
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].
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.
Sidenote: I am not sure why the usage of 'disappearing packages' was
removed from the wiki as dpkg and APT support them in squeeze -
at least in my eyes it looked like the holy grail to prevent maintainers
from using all these half-working tricks in battle against APT, but
i will leave that up to decide for others as IANAD{D,M}.
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?
Best regards
David Kalnischkies
[0] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
[1] http://wiki.debian.org/Renaming_a_Package
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fadhpxlk5b655v0j_+28xg6mvqtnpjpmdzo40xtrax...@mail.gmail.com
Re: Solving lintian warnings for multi-package roxterm
On Thu, 18 Aug 2011 10:41:33 +0200 David Kalnischkies kalnischk...@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. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110818135111.249202cd@junior
Re: Solving lintian warnings for multi-package roxterm
David Kalnischkies kalnischk...@gmail.com writes:
Sidenote: I am not sure why the usage of 'disappearing packages' was
removed from the wiki as dpkg and APT support them in squeeze - at least
in my eyes it looked like the holy grail to prevent maintainers from
using all these half-working tricks in battle against APT, but i will
leave that up to decide for others as IANAD{D,M}.
You can't use disappearing packages with Policy-compliant packages so far
as I can tell, since it would require both packages provide the same
/usr/share/doc directory and changelog file, which is a Policy violation.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uwi9vjf@windlord.stanford.edu
Solving lintian warnings for multi-package roxterm
I've split roxterm in to three packages: roxterm-legacy: binaries compiled and linked with GTK2 roxterm: binaries compiled and linked with GTK3 roxterm-common: All the other files roxterm-legacy and roxterm Conflict with each other and both depend on roxterm-common. I've got 3 lintian warnings: W: roxterm-legacy: menu-icon-missing usr/share/pixmaps/roxterm.xpm W: roxterm: menu-icon-missing usr/share/pixmaps/roxterm.xpm W: roxterm-common: desktop-command-not-in-package usr/share/applications/roxterm.desktop roxterm Should I solve these by duplicating the offending files in roxterm-legacy and roxterm, or keep common copies in roxterm-common and add lintian overrides? Also, roxterm-common currently only Recommends: roxterm | roxterm-legacy. But I think I should make that Depends, especially if I override that last warning. Policy says it is possible, but should be avoided if possible. Avoidance is possible, but a mutual dependency seems the better option to me in this case. Agreed? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110817211944.00634abc@junior
Re: Solving lintian warnings for multi-package roxterm
On Wed, Aug 17, 2011 at 1:19 PM, Tony Houghton h...@realh.co.uk wrote: W: roxterm-legacy: menu-icon-missing usr/share/pixmaps/roxterm.xpm W: roxterm: menu-icon-missing usr/share/pixmaps/roxterm.xpm W: roxterm-common: desktop-command-not-in-package usr/share/applications/roxterm.desktop roxterm Should I solve these by duplicating the offending files in roxterm-legacy and roxterm, or keep common copies in roxterm-common and add lintian overrides? I'd simply override them. Duplicating those files is a waste of space and is unnecessary as long as roxterm(-legacy) depends on roxterm-common. And lintian itself says it's ok to override it: $ lintian-info --tags menu-icon-missing [...] N: If the icon is in a package this package depends on, add a lintian N: override for this warning. lintian cannot check icons in other N: packages. Also, roxterm-common currently only Recommends: roxterm | roxterm-legacy. But I think I should make that Depends, especially if I override that last warning. Policy says it is possible, but should be avoided if possible. Avoidance is possible, but a mutual dependency seems the better option to me in this case. Agreed? No, please avoid circular dependencies/dependency loops. roxterm(-legacy) should depend on roxterm-common, but not the other way around. - Vincent -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBTNi33_87+a+DXg=ha3pdqa4genpubpusq13cinmy...@mail.gmail.com
Re: Solving lintian warnings for multi-package roxterm
On 2011-08-17 22:19, Tony Houghton wrote:
I've split roxterm in to three packages:
roxterm-legacy: binaries compiled and linked with GTK2
roxterm: binaries compiled and linked with GTK3
roxterm-common: All the other files
roxterm-legacy and roxterm Conflict with each other and both depend on
roxterm-common.
I've got 3 lintian warnings:
W: roxterm-legacy: menu-icon-missing usr/share/pixmaps/roxterm.xpm
W: roxterm: menu-icon-missing usr/share/pixmaps/roxterm.xpm
Newer versions of Lintian should have enough information available to
check for this[0]. Feel free to file a wishlist bug against lintian,
requesting that it checks for missing menu icons in direct dependencies
from the same source package.
[0] Assuming all the packages here are built from the same source
package and that roxterm{,-legacy} have a direct strong dependency on
roxterm-common. The latter is true and I guess the former is as well. :)
W: roxterm-common: desktop-command-not-in-package
usr/share/applications/roxterm.desktop roxterm
[...]
Unfortunately this one is technically valid (since roxterm-common does
not have a strong dependency on a package providing the binary). As
Vincent mentioned in a separate reply, the circular dependency is not
necessarily a good choice (and should trigger a new Lintian warning).
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e4c2fe3.1040...@thykier.net
Re: Solving lintian warnings for multi-package roxterm
Hello, On Wed, 17 Aug 2011 21:19:44 +0100 Tony Houghton h...@realh.co.uk wrote: roxterm-legacy: binaries compiled and linked with GTK2 roxterm: binaries compiled and linked with GTK3 roxterm-common: All the other files An off-topic question: why've you chosen this naming scheme? Why 'legacy'? In particular, I'm not going to switch to GTK+3 any time soon, and guess I'm not alone, so it can't be legacy, I think. -- WBR, Andrew signature.asc Description: PGP signature
Re: Solving lintian warnings for multi-package roxterm
Tony Houghton h...@realh.co.uk writes: I've split roxterm in to three packages: roxterm-legacy: binaries compiled and linked with GTK2 roxterm: binaries compiled and linked with GTK3 roxterm-common: All the other files roxterm-legacy and roxterm Conflict with each other and both depend on roxterm-common. I've got 3 lintian warnings: W: roxterm-legacy: menu-icon-missing usr/share/pixmaps/roxterm.xpm W: roxterm: menu-icon-missing usr/share/pixmaps/roxterm.xpm W: roxterm-common: desktop-command-not-in-package usr/share/applications/roxterm.desktop roxterm I would leave the menu icon in roxterm-common, but I would indeed move the desktop entry into the separate packages. In general, one should put the desktop file in the package that also contains the command. The amount of space savings by putting that tiny text file in a separate common package just isn't worth it, and that way the desktop file is only installed when the command is available. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3g3647o@windlord.stanford.edu
Re: Solving lintian warnings for multi-package roxterm
On Thu, 18 Aug 2011 01:30:55 +0300 Andrew O. Shadoura bugzi...@tut.by wrote: On Wed, 17 Aug 2011 21:19:44 +0100 Tony Houghton h...@realh.co.uk wrote: roxterm-legacy: binaries compiled and linked with GTK2 roxterm: binaries compiled and linked with GTK3 roxterm-common: All the other files An off-topic question: why've you chosen this naming scheme? Why 'legacy'? In particular, I'm not going to switch to GTK+3 any time soon, and guess I'm not alone, so it can't be legacy, I think. I'm glad you asked TBH, because I wasn't happy about that name either. I think I might use the name roxterm-gtk2 instead. To make it easier for people who want to stay with GTK2 I could either add a line to the GTK3 one's description referring to the GTK2 version or rename the GTK3-based 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? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110818003937.6f2465f0@junior
