desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
 

Hi folks,

How to deal with a desktop-command-not-in-package lintian warning when a
.desktop file in a "common" package B references a binary in package A ?


Typically the package A used to contain static/arch-independent data
which was splitted to a B "common" package to comply with debian
packaging rules (to limit the size of architecture-dependent packages).


Solution 1: consider the warning a false positive and ignore it
Solution 2: pull back the destop command in the arch-dependent package

(I can not reverse the dependencies, because A _do_ depends on data in B.)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
 

Am Sonntag, den 10.01.2010, 14:30 +0100 schrieb Xavier Roche:
> Hi folks,
>
> How to deal with a desktop-command-not-in-package lintian warning when a
> .desktop file in a "common" package B references a binary in package A ?
>
> Typically the package A used to contain static/arch-independent data
> which was splitted to a B "common" package to comply with debian
> packaging rules (to limit the size of architecture-dependent packages).
>
> Solution 1: consider the warning a false positive and ignore it
> Solution 2: pull back the destop command in the arch-dependent package

Solution 2 is the correct answer.

> (I can not reverse the dependencies, because A _do_ depends on data in B.)

First I thought it would be a strange warning, but then I understood it.
Imagine that you install only the data package B, which contains the
desktop file. Then you have a desktop icon, but you cannot launch the
application.

--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)

desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
 

On Sun, Jan 10, 2010 at 03:15:30PM +0100, Benjamin Drung wrote:
> Am Sonntag, den 10.01.2010, 14:30 +0100 schrieb Xavier Roche:
> > Hi folks,
> >
> > How to deal with a desktop-command-not-in-package lintian warning when a
> > .desktop file in a "common" package B references a binary in package A ?
> >
> > Typically the package A used to contain static/arch-independent data
> > which was splitted to a B "common" package to comply with debian
> > packaging rules (to limit the size of architecture-dependent packages).
> >
> > Solution 1: consider the warning a false positive and ignore it
> > Solution 2: pull back the destop command in the arch-dependent package
>
> Solution 2 is the correct answer.

For me solution 1 is also justified when putting the .desktop file into
the arch-dependent package. Since the arch-dependent package depends
on the common package lintian shouldn't complain, otherwise a
bug report against lintian might be in order.

> First I thought it would be a strange warning, but then I understood it.
> Imagine that you install only the data package B, which contains the
> desktop file. Then you have a desktop icon, but you cannot launch the
> application.

True, but this is really an exceptional case. I suspect the normal case is
that one installs both packages.

-Ralf.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
 

Hi Ralf ,

Ralf Treinen a écrit :

For me solution 1 is also justified when putting the .desktop file into
the arch-dependent package. Since the arch-dependent package depends
on the common package lintian shouldn't complain


Well, at first glance I wanted to make the two packages cross-dependend
(A depends on B and B depends on A) for force the installing of both
packages at the same time. This was not a good idea, of course.



True, but this is really an exceptional case. I suspect the normal case is
that one installs both packages.


Yep, exactly. OTOH, I will just move the small desktop file in the
arch-dependent one, which is going to spoil some additional bytes, but
nothing too serious fortunately :)


The only consequence is a typical conflict when installing the new
package because a file was moved from a package to another one, with
dependency issues (something I already experienced):


installed:package A
installed:package B contains <desktop file>
new:package A [new version] contains <desktop file>
new:package B [new version]

Typicall update step when updating A:
- A depends on B, will update B later
- remove A
- installing new A, but <desktop file> already exist
==> FAIL

Playing with 'Conflicts: A (<= old), B (<= old)' and/or 'Replaces: A (<=
old), B (<= old)' does not seem to do any good. Humm, I'm wondering if
the "Let's ignore the minor lintian warning" is not the correct solution
after all.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
 

On Sun, Jan 10, 2010 at 03:47:39PM +0100, Xavier Roche wrote:
> Ralf Treinen a écrit :
> >True, but this is really an exceptional case. I suspect the normal case is
> >that one installs both packages.
>
> Yep, exactly. OTOH, I will just move the small desktop file in the
> arch-dependent one, which is going to spoil some additional bytes,
> but nothing too serious fortunately :)
>
> The only consequence is a typical conflict when installing the new
> package because a file was moved from a package to another one, with
> dependency issues (something I already experienced):

One uses Replaces to indicate that there is a file conflict.

> installed:package A
> installed:package B contains <desktop file>
> new:package A [new version] contains <desktop file>
> new:package B [new version]
>
> Typicall update step when updating A:
> - A depends on B, will update B later
> - remove A
> - installing new A, but <desktop file> already exist
> ==> FAIL

Package: A
Depends: B
Conflicts: B (<< newversion)
Replaces: B (<< newversion)

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>

desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
 

On Sun, Jan 10, 2010 at 15:47:39 +0100, Xavier Roche wrote:

> The only consequence is a typical conflict when installing the new
> package because a file was moved from a package to another one, with
> dependency issues (something I already experienced):
>
> installed:package A
> installed:package B contains <desktop file>
> new:package A [new version] contains <desktop file>
> new:package B [new version]
>
> Typicall update step when updating A:
> - A depends on B, will update B later
> - remove A
> - installing new A, but <desktop file> already exist
> ==> FAIL
>
> Playing with 'Conflicts: A (<= old), B (<= old)' and/or 'Replaces: A
> (<= old), B (<= old)' does not seem to do any good. Humm, I'm
> wondering if the "Let's ignore the minor lintian warning" is not the
> correct solution after all.
>
No. You don't need any conflicts, you need
Replaces: B (<< new)
in the new A and upgrades will work just fine.

Cheers,
Julien


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
 

Julien Cristau a écrit :

No. You don't need any conflicts, you need
Replaces: B (<< new)
in the new A and upgrades will work just fine.


Yes, works fine, thanks! One more lintian warning removed :)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
 

Ralf Treinen <treinen@free.fr> writes:

> For me solution 1 is also justified when putting the .desktop file into
> the arch-dependent package. Since the arch-dependent package depends on
> the common package lintian shouldn't complain, otherwise a bug report
> against lintian might be in order.

I think it's mildly better to keep the *.desktop file with the binary.
It's not large, and that avoids problems if the binary package is removed
and the data package isn't for some reason.

That being said, that's not why Lintian is warning. Lintian is warning
because structural limitations in Lintian don't give it any way of doing
cross-package queries. In other words, while it's checking the binary
package, it has no idea what's in the data package. There are multiple
open bugs about this, but it will require a significant rearchitecture to
address it (even in those cases where it can be addressed, which it can't
always).

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org