.desktop files of GNOME apps and path to these applications

[Vincent Lefevre]

Hi,

The .desktop file distributed with the evince package
(/usr/share/applications/evince.desktop) contains:

  Exec=evince %U

meaning that the user's $PATH is taken into account. In general,
taking $PATH into account is recommended, but IMHO, this should
not be the case here, because of the following points (related
to each other):

1. This .desktop file is a file associated with /usr/bin/evince
   (distributed in the same package...).

2. Taking the user's $PATH into account may have unexpected effects,
   such as running a different version of evince which may accept a
   different set of MIME types, or worse, running an evince program
   that has a completely different behavior: the user (who may be
   different from the administrator of the machine and may not know
   GNOME's evince) may have written a program called "evince" (FYI,
   this is a French word that means "oust") and installed it in his
   $HOME/bin directory.

3. In config files, $PATH is generally used when one doesn't know
   the location of the program, for flexibility, but this is not
   the case here (see point 1).

Here the choice of specifying an executable relative to $PATH should
only be a choice made by the user himself.

Other packages may be affected by the same problem.

Note that this is a followup to bug 488971:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488971

(With xulrunner-1.9-gnome-support, iceweasel announces e.g. xpdf,
but actually launches evince.)

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .desktop files of GNOME apps and path to these applications

[Vincent Zweije]

On Wed, Jul 09, 2008 at 01:14:25PM +0200, Vincent Lefevre wrote:

||  The .desktop file distributed with the evince package
||  (/usr/share/applications/evince.desktop) contains:
||
||Exec=evince %U
||
||  meaning that the user's $PATH is taken into account. In general,
||  taking $PATH into account is recommended, but IMHO, this should
||  not be the case here, because of the following points (related
||  to each other):
||
||  1. This .desktop file is a file associated with /usr/bin/evince
|| (distributed in the same package...).

NFS-mounted /home could be used on multiple computers, where the same
(compatible) evince is installed at different locations.

||  2. Taking the user's $PATH into account may have unexpected effects,
|| such as running a different version of evince which may accept a
|| different set of MIME types, or worse, running an evince program
|| that has a completely different behavior: the user (who may be
|| different from the administrator of the machine and may not know
|| GNOME's evince) may have written a program called "evince" (FYI,
|| this is a French word that means "oust") and installed it in his
|| $HOME/bin directory.

A user who is clever enough to extend his PATH should clever enough to
find out why his evince script is suddenly being executed.

||  3. In config files, $PATH is generally used when one doesn't know
|| the location of the program, for flexibility, but this is not
|| the case here (see point 1).

PATH is part of the environment. An eminent use of environment is to
inform programs of precisely that: their environment, such as where
other programs are to be found. Use it, that's what it's for.

Not using PATH to locate programs would be an exception to this rule. You
don't want exceptions, because it hampers the predictability of the
system.

||  Note that this is a followup to bug 488971:
||
||http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488971
||
||  (With xulrunner-1.9-gnome-support, iceweasel announces e.g. xpdf,
||  but actually launches evince.)

That bug is more about firefox not running the helper application that
is says it is going to run (by whatever cause).

Writing a script with destructive potential and putting it in front
in your PATH has a dangerous potential. This can aggravate the impact
of #488971, but it is still a bug in firefox or in its neighborhood,
not in PATH searching.

Ciao.Vincent.
-- 
Vincent Zweije <[EMAIL PROTECTED]>| "If you're flamed in a group you
  | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r.


signature.asc
Description: Digital signature

Re: Bug#489824: ITP: pllua -- PL/Lua is an implementation of Lua as a loadable procedural language for PostgreSQL

[Chris Bannister]

On Tue, Jul 08, 2008 at 02:01:13PM +1000, Ben Finney wrote:
> 
> On that basis, a better synopsis would be:
> 
> PL/Lua procedural language for PostgreSQL

So the short description can start with a capital letter?

-- 
Chris.
==
"One, with God, is always a majority, but many a martyr has been burned
   at the stake while the votes were being counted."  -- Thomas B. Reed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Comparison between Destkop entry and Debian menu specifications.

[Charles Plessy]

Le Wed, Jul 09, 2008 at 12:12:23AM +0200, Wouter Verhelst a écrit :
> XDG has less features than debian-menu currently does. For
> instance, unless I'm mistaken it's not possible to specify in an XDG
> .desktop file that a particular application is a curses or similar
> application that requires an xterm or some such, which is possible with
> menu. Due to this feature, it's also possible to have a package like
> pdmenu for non-graphical systems.

Hi Wouter,

There is of course not perfect mapping between the fields of the Menu
entries and the keys of the Desktop entries, but still there is an
overall good correspondance. Main differences are:

1) Desktop entries are not designed to deal with switching window
managers nor with Linux console applications. (However, the Desktop
entry specification can be extended by keys prefixed by 'X-').

2) Menu entries distinguish section and hints, while Desktop entries
permit multiple Categories, and delegate to the Desktop menu
specification to sort out between "Main" categories ( ~ sections) and
"Additional" categories ( ~ hints).


The other differences are actually between the Debian menu system and
the Destkop menu specification:

1) The menu structure is not exactly the same, although the overlap is
again large.

2) One can use any hint, but the list of "Additionnal" categories is
fixed.


I have drafted a comparison page on the Wiki. After Lenny release, it
could be the base for the drafting of a Debian enhancement proposal.

http://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries

Have a nice day,

-- 
Charles Plessy
Debian-Med packaging team,
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#489824: ITP: pllua -- PL/Lua is an implementation of Lua as a loadable procedural language for PostgreSQL

[Steinar H. Gunderson]

On Thu, Jul 10, 2008 at 01:43:12AM +1200, Chris Bannister wrote:
>> On that basis, a better synopsis would be:
>> 
>> PL/Lua procedural language for PostgreSQL
> So the short description can start with a capital letter?

Certainly, since PL is an acronym.

I'd say "procedural language for PostgreSQL based on Lua" would be a better
short description, though, but consistency with the others is nice to have as
well.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .desktop files of GNOME apps and path to these applications

[Roberto C . Sánchez]

On Wed, Jul 09, 2008 at 02:46:22PM +0200, Vincent Zweije wrote:
> On Wed, Jul 09, 2008 at 01:14:25PM +0200, Vincent Lefevre wrote:
> 
> ||  The .desktop file distributed with the evince package
> ||  (/usr/share/applications/evince.desktop) contains:
> ||
> ||Exec=evince %U
> ||
> ||  meaning that the user's $PATH is taken into account. In general,
> ||  taking $PATH into account is recommended, but IMHO, this should
> ||  not be the case here, because of the following points (related
> ||  to each other):
> ||
> ||  1. This .desktop file is a file associated with /usr/bin/evince
> || (distributed in the same package...).
> 
> NFS-mounted /home could be used on multiple computers, where the same
> (compatible) evince is installed at different locations.
> 
This is especially true in the case of an environment with multiple
Linux distros (or even with other operating systems, now that Solaris
ships with GNOME).

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: .desktop files of GNOME apps and path to these applications

[Mike Hommey]

On Wed, Jul 09, 2008 at 12:01:47PM -0400, Roberto C. Sánchez wrote:
> On Wed, Jul 09, 2008 at 02:46:22PM +0200, Vincent Zweije wrote:
> > On Wed, Jul 09, 2008 at 01:14:25PM +0200, Vincent Lefevre wrote:
> > 
> > ||  The .desktop file distributed with the evince package
> > ||  (/usr/share/applications/evince.desktop) contains:
> > ||
> > ||Exec=evince %U
> > ||
> > ||  meaning that the user's $PATH is taken into account. In general,
> > ||  taking $PATH into account is recommended, but IMHO, this should
> > ||  not be the case here, because of the following points (related
> > ||  to each other):
> > ||
> > ||  1. This .desktop file is a file associated with /usr/bin/evince
> > || (distributed in the same package...).
> > 
> > NFS-mounted /home could be used on multiple computers, where the same
> > (compatible) evince is installed at different locations.
> > 
> This is especially true in the case of an environment with multiple
> Linux distros (or even with other operating systems, now that Solaris
> ships with GNOME).

.desktop files are in /usr/share/applications. This is likely to *not*
be shared.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: Triangle -- Two-dimensional quality mesh generator and Delaunay triangulator

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Package name: triangle
Version: 1.6
Author: Jonathan Richard Shewchuk <[EMAIL PROTECTED]>
License: non-free (distribution for fee prohibited)
URL: http://www.cs.cmu.edu/~quake/triangle.html
Description: Two-dimensional quality mesh generator and Delaunay triangulator

Triangle is a nice mesh generator which is currently distributed as part
of the Debian opencascade package (as version 1.4).  This is (probably)
the only explicitly non-free part of that package (though Debian has not
registered an official position on the Open Cascade Technology Public
License), so splitting it out would allow the rest of opencascade to go
into contrib.  Splitting it out would also allow other packages to link
directly to it, which is currently difficult in opencascade, as triangle
is buried in libTKMesh.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part

Re: Bug#489824: ITP: pllua -- PL/Lua is an implementation of Lua as a loadable procedural language for PostgreSQL

[Fernando Ike de Oliveira]

Em Qua, 2008-07-09 às 15:35 +0200, Steinar H. Gunderson escreveu:
> On Thu, Jul 10, 2008 at 01:43:12AM +1200, Chris Bannister wrote:
> >> On that basis, a better synopsis would be:
> >> 
> >> PL/Lua procedural language for PostgreSQL
> > So the short description can start with a capital letter?
> 
> Certainly, since PL is an acronym.
> 
> I'd say "procedural language for PostgreSQL based on Lua" would be a better
> short description, though, but consistency with the others is nice to have as
> well.

  Of course. PL/Perl, PL/Python and PL/TCL are with short description
"PL/*** procedural language for PostgreSQL 8.X. I beliave that describe
wrote per Steinar is better and more clean. 


Cheers,
-- 
Fernando Ike de Oliveira <[EMAIL PROTECTED]>


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .desktop files of GNOME apps and path to these applications

[Vincent Lefevre]

On 2008-07-09 14:46:22 +0200, Vincent Zweije wrote:
> On Wed, Jul 09, 2008 at 01:14:25PM +0200, Vincent Lefevre wrote:
> ||  The .desktop file distributed with the evince package
> ||  (/usr/share/applications/evince.desktop) contains:
> ||
> ||Exec=evince %U
> ||
> ||  meaning that the user's $PATH is taken into account. In general,
> ||  taking $PATH into account is recommended, but IMHO, this should
> ||  not be the case here, because of the following points (related
> ||  to each other):
> ||
> ||  1. This .desktop file is a file associated with /usr/bin/evince
> || (distributed in the same package...).
> 
> NFS-mounted /home could be used on multiple computers, where the same
> (compatible) evince is installed at different locations.

You didn't read my mail. I'm talking about Debian's evince package,
for which evince is installed in /usr/bin. Also, the .desktop file
distributed with this package is not in /home, but in
/usr/share/applications/.

If the .desktop file is there to work also with other evince binaries
(installed elsewhere), then it shouldn't be distributed in the evince
package, but in a more general package for GNOME support. Indeed, if
the evince application is installed somewhere else and the user wants
to run this version, then he doesn't need the evince package.

> ||  3. In config files, $PATH is generally used when one doesn't know
> || the location of the program, for flexibility, but this is not
> || the case here (see point 1).
> 
> PATH is part of the environment. An eminent use of environment is to
> inform programs of precisely that: their environment, such as where
> other programs are to be found. Use it, that's what it's for.

Again you missed the point: it is useless here since the evince
provided by the evince package is in /usr/bin. If the user has an
evince installed somewhere else, see the above discussion.

> Not using PATH to locate programs would be an exception to this
> rule. You don't want exceptions, because it hampers the
> predictability of the system.

Depending on the environment makes the system less predictable.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: .desktop files of GNOME apps and path to these applications

[Josselin Mouette]

Le mercredi 09 juillet 2008 à 13:14 +0200, Vincent Lefevre a écrit :
> 3. In config files, $PATH is generally used when one doesn't know
>the location of the program, for flexibility, but this is not
>the case here (see point 1).
> 
> Here the choice of specifying an executable relative to $PATH should
> only be a choice made by the user himself.
> 
> Other packages may be affected by the same problem.

This is a valid concern; we are already hardcoding paths for gnome-games
because their being in /usr/games is much more often a problem, but I
don’t see a good reason for not doing it for other files.

I have asked the question on the upstream ML in the hope we can fix this
issue directly.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#489824: ITP: pllua -- PL/Lua is an implementation of Lua as a loadable procedural language for PostgreSQL

[Ben Finney]

Chris Bannister <[EMAIL PROTECTED]> writes:

> On Tue, Jul 08, 2008 at 02:01:13PM +1000, Ben Finney wrote:
> > 
> > On that basis, a better synopsis would be:
> > 
> > PL/Lua procedural language for PostgreSQL
> 
> So the short description can start with a capital letter?

Sure, if it would make sense for it to be capitalised that way in an
appositive clause. PL is an acronym used within the PostgreSQL project
for "procedural language (that can be dynamically loaded)".

The test to apply is: does the synopsis make sense if it is put into
the following template:

 is {the,a,an} 

-- 
 \   “[On the Internet,] power and control will shift to those who |
  `\   are actually contributing something useful rather than just |
_o__)having lunch.” —Douglas Adams |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#490135: RFP: fdmf -- find duplicate music files

[Paul Wise]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, [EMAIL PROTECTED]

* Package name: fdmf
  Version : 0.0.9r
  Upstream Author : Kurt Rosenfeld
* URL : http://w140.com/audio/
* License : GPL
  Programming Lang: C, Perl
  Description : find duplicate music files

fdmf finds pairs of music files in a collection that are likely to
contain the same music. It works on the music itself, not on the
filename, tags, or headers. It uses an audio fingerprint, or perceptual
hash to recognise the duplicate files.

I intend to ITP this at some point, probably after lenny is released,
but I would be very glad if someone else wants to take it over. Haven't
yet evaluated how good it is.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part