Re: Desktop standards, MIME info cache, and Lintian

2009-02-27 Thread Raphael Geissert
Michael Biebl wrote:
[...]
 It's also a matter for what case we optimize:
 
 For users running unstable, who constantly update, it might/will happen
 that the update-desktop-database trigger is activated although
 unnecessary.
 
 For stable users, who only do distro upgrades, it might be quite some
 benefit,
 as instead of dozens of  update-desktop-database calls during the upgrade,
 you'd only get one.

Why not implement a system that maintainer scripts could use to tell dpkg
that a given script or 'not automagic trigger' is needed, that would only
be enabled when a package really needs it; but the operation would be done
just once.

Cheers,
Raphael Geissert



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



Re: Desktop standards, MIME info cache, and Lintian

2009-02-12 Thread Emilio Pozuelo Monfort
Josselin Mouette wrote:
 As for update-mime-database, I think it concerns only a very small
 number of packages, but that’s certainly doable.

I've looked into update-mime-database and update-mime. Here's what I think needs
to be done in order to properly adopt triggers support in these packages:

1) Once Lenny is released, upload shared-mime-info and mime-support with
triggers support to unstable (I have patches for both).

2) Once both shared-mime-info and mime-support are in testing, upload a new
debhelper that doesn't add post{inst,rm} snippets for update-mime(-database)
(patch ready too).

3) Add new lintian tags: script-calls-update-mime-database-directly and
script-calls-update-mime-directly.

How does this sound?

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature


Re: Desktop standards, MIME info cache, and Lintian

2009-02-11 Thread Emilio Pozuelo Monfort
Michael Biebl wrote:
 See /usr/share/doc/dpkg-dev/triggers.txt.gz, w.r.t file triggers.
 The trigger will one be run if it matches a file (e.g. /usr/share/icons or
 /usr/share/applications).


James Vega wrote:
 The whole point of triggers is that they watch a set of
 files/directories and when changes happen to those files/directories a
 command gets run.  They're supposed to make it so that only one package (the
 one providing the command that needs to be run) has to know that the command
 needs to be run.  This is far less error-prone than relying on every developer
 to remember which commands to run in which maintainer scripts.

Thank you both for the pointers, I clearly was totally confused about how
triggers work.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature


Re: Desktop standards, MIME info cache, and Lintian

2009-02-11 Thread Michael Biebl
Mike Hommey wrote:
 On Tue, Feb 10, 2009 at 12:03:27PM +0100, Loïc Minier wrote:
 On Tue, Feb 10, 2009, Josselin Mouette wrote:
 I don’t think it’s a good idea to use triggers for
 update-desktop-database. There are many .desktop files without a
 MimeType key, and for all of them calling update-desktop-database is a
 waste of time. 

 On my system, only 30% of .desktop files have a MimeType field. If
 anyone can make per-package statistics on the whole archive, that would
 probably give a better picture.
  It's once per upgrade and ridiculously cheap; I don't think the waste
  of time is an argument.  However this probably makes the direct calls
  in maintainer scripts as cheap.  The only arguments in favor of
  triggers here are:
- single place to fix/hack where all the calls are done
- avoids a dh_foo call or custom hackery for packages not using
  debhelper
  and these aren't as compelling as the time to upgrade argument which is
  usually the reason for triggers.

  sudo update-desktop-database -q  0,06s user 0,02s system 96% cpu 0,075 total
 
 Is that with cold cache ?
 

It's also a matter for what case we optimize:

For users running unstable, who constantly update, it might/will happen that the
update-desktop-database trigger is activated although unnecessary.

For stable users, who only do distro upgrades, it might be quite some benefit,
as instead of dozens of  update-desktop-database calls during the upgrade, you'd
only get one.

I let others decide what is more important.

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Re: Desktop standards, MIME info cache, and Lintian

2009-02-11 Thread Josselin Mouette
Le mardi 10 février 2009 à 19:27 +0100, Michael Biebl a écrit :
 Josselin Mouette wrote:
  For update-icon-caches, that was the plan when introducing it. However
  it can only apply to the hicolor and gnome themes. Other themes will
  still need to call dh_icons. This also means dh_icons will have to
  special-case these directories.
 
 Could you elaborate a bit more on that, which directories precisely and why
 other themes still need dh_icons?

update-icon-caches needs to be run once for each icon directory where a
package installs icons. As triggers can’t tell you which subdirectory
was modified, a global trigger for /usr/share/icons is not the way to
go.

Therefore, there must be a trigger for /usr/share/icons/hicolor and one
for /usr/share/icons/gnome. Other icon themes are generally the matter
of only one package, so they can be made to run update-icon-caches using
dh_icons just as they do currently.

 If I can get a clear picture what exactly needs to be done, I don't think it
 would that hard to provide patches (and I'd be willingly to do so).

One thing that should not be forgotten (among others):
update-icon-caches must be made unconditional in the same version of
libgtk2.0-bin the trigger is added. (Currently it only refreshes
existing caches.)

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: Desktop standards, MIME info cache, and Lintian

2009-02-10 Thread Josselin Mouette
Le dimanche 08 février 2009 à 18:34 -0800, Russ Allbery a écrit :
 I removed the requirement to call dh_desktop every time you have a
 *.desktop file.  I didn't remove the tag entirely since at the time we had
 no triggers and you still did need to call update-desktop-database if the
 *.desktop file has a MimeType key.
 
 If there's a trigger now that handles this, I'll remove that as well.  Was
 one added?

I don’t think it’s a good idea to use triggers for
update-desktop-database. There are many .desktop files without a
MimeType key, and for all of them calling update-desktop-database is a
waste of time. 

On my system, only 30% of .desktop files have a MimeType field. If
anyone can make per-package statistics on the whole archive, that would
probably give a better picture.

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: Desktop standards, MIME info cache, and Lintian

2009-02-10 Thread Loïc Minier
On Tue, Feb 10, 2009, Josselin Mouette wrote:
 I don’t think it’s a good idea to use triggers for
 update-desktop-database. There are many .desktop files without a
 MimeType key, and for all of them calling update-desktop-database is a
 waste of time. 
 
 On my system, only 30% of .desktop files have a MimeType field. If
 anyone can make per-package statistics on the whole archive, that would
 probably give a better picture.

 It's once per upgrade and ridiculously cheap; I don't think the waste
 of time is an argument.  However this probably makes the direct calls
 in maintainer scripts as cheap.  The only arguments in favor of
 triggers here are:
   - single place to fix/hack where all the calls are done
   - avoids a dh_foo call or custom hackery for packages not using
 debhelper
 and these aren't as compelling as the time to upgrade argument which is
 usually the reason for triggers.

 sudo update-desktop-database -q  0,06s user 0,02s system 96% cpu 0,075 total

-- 
Loïc Minier


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



Re: Desktop standards, MIME info cache, and Lintian

2009-02-10 Thread Josselin Mouette
Le mardi 10 février 2009 à 12:03 +0100, Loïc Minier a écrit :
  sudo update-desktop-database -q  0,06s user 0,02s system 96% cpu 0,075 total

I didn’t recall it was that cheap. The trigger is then definitely the
way to go.

-- 
 .''`.
: :' :  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: Desktop standards, MIME info cache, and Lintian

2009-02-10 Thread Michael Biebl
Josselin Mouette wrote:
 Le mardi 10 février 2009 à 12:03 +0100, Loïc Minier a écrit :
  sudo update-desktop-database -q  0,06s user 0,02s system 96% cpu 0,075 total
 
 I didn’t recall it was that cheap. The trigger is then definitely the
 way to go.
 

Joss, what's your opintion on update-mime-database (dh_installmime) and
update-icon-caches (dh_icons)?
Should we triggerize them too?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Re: Desktop standards, MIME info cache, and Lintian

2009-02-10 Thread Josselin Mouette
Le mardi 10 février 2009 à 13:34 +0100, Michael Biebl a écrit :
 Joss, what's your opintion on update-mime-database (dh_installmime) and
 update-icon-caches (dh_icons)?
 Should we triggerize them too?

As for update-mime-database, I think it concerns only a very small
number of packages, but that’s certainly doable.

For update-icon-caches, that was the plan when introducing it. However
it can only apply to the hicolor and gnome themes. Other themes will
still need to call dh_icons. This also means dh_icons will have to
special-case these directories.

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: Desktop standards, MIME info cache, and Lintian

2009-02-10 Thread Michael Biebl
Josselin Mouette wrote:
 Le mardi 10 février 2009 à 13:34 +0100, Michael Biebl a écrit :
 Joss, what's your opintion on update-mime-database (dh_installmime) and
 update-icon-caches (dh_icons)?
 Should we triggerize them too?
 
 For update-icon-caches, that was the plan when introducing it. However
 it can only apply to the hicolor and gnome themes. Other themes will
 still need to call dh_icons. This also means dh_icons will have to
 special-case these directories.

Could you elaborate a bit more on that, which directories precisely and why
other themes still need dh_icons?
If I can get a clear picture what exactly needs to be done, I don't think it
would that hard to provide patches (and I'd be willingly to do so).

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Re: Desktop standards, MIME info cache, and Lintian

2009-02-10 Thread Mike Hommey
On Tue, Feb 10, 2009 at 12:03:27PM +0100, Loïc Minier wrote:
 On Tue, Feb 10, 2009, Josselin Mouette wrote:
  I don’t think it’s a good idea to use triggers for
  update-desktop-database. There are many .desktop files without a
  MimeType key, and for all of them calling update-desktop-database is a
  waste of time. 
  
  On my system, only 30% of .desktop files have a MimeType field. If
  anyone can make per-package statistics on the whole archive, that would
  probably give a better picture.
 
  It's once per upgrade and ridiculously cheap; I don't think the waste
  of time is an argument.  However this probably makes the direct calls
  in maintainer scripts as cheap.  The only arguments in favor of
  triggers here are:
- single place to fix/hack where all the calls are done
- avoids a dh_foo call or custom hackery for packages not using
  debhelper
  and these aren't as compelling as the time to upgrade argument which is
  usually the reason for triggers.
 
  sudo update-desktop-database -q  0,06s user 0,02s system 96% cpu 0,075 total

Is that with cold cache ?

Mike


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



Re: Desktop standards, MIME info cache, and Lintian

2009-02-08 Thread Michael Biebl
Russ Allbery wrote:
 Loïc Minier l...@dooz.org writes:
 
  I can see how it would be useful to recommend calling dh_desktop as
  soon as you distribute .desktop files just like it would be more useful
  if we could inject any rules in packages via cdbs or the new dh.
  However, this is really packaging style and using an extensible
  packaging style shouldn't be imposed by a checker tool like lintian;
  I'm not aware of any different dh_desktop usage which would justify
  raising a warning right now.

  Also, would we have to do more things on .desktop files, we would have
  more options to implement them without requiring dh_desktop (triggers
  come to mind).

  So not raising a lintian warning when dh_desktop isn't called on
  .desktop file would be more to my taste.
 
 Okay, that matches my reasoning.  I'll remove that tag in the next version
 of Lintian.  Thank you very much!


Maybe i missinterpreted your conclusion, but this what I get in one of my 
packages:
 desktop-mimetype-without-update-call /usr/share/applications/...

Now that we have triggers, I really don't see the benefit of adding such a
lintian warning. Imho we should get rid of dh_icon and dh_desktop completely and
also any manual update-desktop-database calls, not recommend to add such a call
(to potentially a *lot* of packages).

Why should we update dozens if not hundreds of packages, if we can have the same
effect much more elegantly and efficiently with file triggers.

FWIW, I'd recommend to update desktop-file-utils (update-desktop-database),
shared-mime-info (update-mime-database) and libgtk2.0-bin (update-icon-caches),
to provide proper triggers support and as soon as that has happened even reverse
the lintian check, i.e. if it finds any dh_icons / dh_desktop /
update-desktop-database call, issue a warning with the recommendation to remove 
it.

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Re: Desktop standards, MIME info cache, and Lintian

2009-02-08 Thread Emilio Pozuelo Monfort
Michael Biebl wrote:
 Maybe i missinterpreted your conclusion, but this what I get in one of my 
 packages:
  desktop-mimetype-without-update-call /usr/share/applications/...
 
 Now that we have triggers, I really don't see the benefit of adding such a
 lintian warning. Imho we should get rid of dh_icon and dh_desktop completely 
 and
 also any manual update-desktop-database calls, not recommend to add such a 
 call
 (to potentially a *lot* of packages).
 
 Why should we update dozens if not hundreds of packages, if we can have the 
 same
 effect much more elegantly and efficiently with file triggers.

How would you know the trigger needs to be run then? If you remove the call from
all the packages, you will then have to call the trigger everytime dpkg is run,
no matter if you only install one package that doesn't need those triggers.

So AFAIUI, your package needs to call those, and then dpkg will not call those
for every package, but do one call at the end if it supports triggers.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature


Re: Desktop standards, MIME info cache, and Lintian

2009-02-08 Thread James Vega
On Sun, Feb 08, 2009 at 09:21:10PM +0100, Emilio Pozuelo Monfort wrote:
 Michael Biebl wrote:
  Maybe i missinterpreted your conclusion, but this what I get in one of my 
  packages:
   desktop-mimetype-without-update-call /usr/share/applications/...
  
  Now that we have triggers, I really don't see the benefit of adding such a
  lintian warning. Imho we should get rid of dh_icon and dh_desktop 
  completely and
  also any manual update-desktop-database calls, not recommend to add such a 
  call
  (to potentially a *lot* of packages).
  
  Why should we update dozens if not hundreds of packages, if we can have the 
  same
  effect much more elegantly and efficiently with file triggers.
 
 How would you know the trigger needs to be run then? If you remove the call 
 from
 all the packages, you will then have to call the trigger everytime dpkg is 
 run,
 no matter if you only install one package that doesn't need those triggers.

The whole point of triggers is that they watch a set of
files/directories and when changes happen to those files/directories a
command gets run.  They're supposed to make it so that only one package (the
one providing the command that needs to be run) has to know that the command
needs to be run.  This is far less error-prone than relying on every developer
to remember which commands to run in which maintainer scripts.

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


signature.asc
Description: Digital signature


Re: Desktop standards, MIME info cache, and Lintian

2009-02-08 Thread Michael Biebl
Emilio Pozuelo Monfort wrote:
 Michael Biebl wrote:
 Maybe i missinterpreted your conclusion, but this what I get in one of my 
 packages:
  desktop-mimetype-without-update-call /usr/share/applications/...

 Now that we have triggers, I really don't see the benefit of adding such a
 lintian warning. Imho we should get rid of dh_icon and dh_desktop completely 
 and
 also any manual update-desktop-database calls, not recommend to add such a 
 call
 (to potentially a *lot* of packages).

 Why should we update dozens if not hundreds of packages, if we can have the 
 same
 effect much more elegantly and efficiently with file triggers.
 
 How would you know the trigger needs to be run then? If you remove the call 
 from
 all the packages, you will then have to call the trigger everytime dpkg is 
 run,
 no matter if you only install one package that doesn't need those triggers.
 
 So AFAIUI, your package needs to call those, and then dpkg will not call those
 for every package, but do one call at the end if it supports triggers.
 

See /usr/share/doc/dpkg-dev/triggers.txt.gz, w.r.t file triggers.
The trigger will one be run if it matches a file (e.g. /usr/share/icons or
/usr/share/applications).

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Re: Desktop standards, MIME info cache, and Lintian

2009-02-08 Thread Russ Allbery
Michael Biebl bi...@debian.org writes:
 Russ Allbery wrote:

 Okay, that matches my reasoning.  I'll remove that tag in the next
 version of Lintian.  Thank you very much!

 Maybe i missinterpreted your conclusion, but this what I get in one of
 my packages:

  desktop-mimetype-without-update-call /usr/share/applications/...

 Now that we have triggers, I really don't see the benefit of adding such
 a lintian warning. Imho we should get rid of dh_icon and dh_desktop
 completely and also any manual update-desktop-database calls, not
 recommend to add such a call (to potentially a *lot* of packages).

I removed the requirement to call dh_desktop every time you have a
*.desktop file.  I didn't remove the tag entirely since at the time we had
no triggers and you still did need to call update-desktop-database if the
*.desktop file has a MimeType key.

If there's a trigger now that handles this, I'll remove that as well.  Was
one added?

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


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



Re: Desktop standards, MIME info cache, and Lintian

2008-12-29 Thread Loïc Minier
On Sun, Dec 28, 2008, Russ Allbery wrote:
 1. The update-desktop-database program used to be documented in the
desktop entry spec in version 0.9.5 and was removed in 0.9.6 (the
current version is 1.0).  Should I draw some conclusion from that?  Is
this program and cache likely to go away?  Is it still really used?
(It also seems odd that a cache regenerated from installed files is
written to /usr/share rather than in /var.)

 (I have no idea why it's not mentionned anymore.)  Yes, the program is
 still used; it's in charge of generating
   /usr/share/applications/mimeinfo.cache (and
 /usr/local/share/applications/mimeinfo.cache); these files may then be
 used by e.g. gio (in GLib) to map MIME types to .desktop files
 (really applications).  This can be used for example to open web
 objects with the correct application according to its MIME type, or via
 shared-mime-info + gio -- which allow mapping of a file's content or
 filename to a MIME type -- to open any file with an application
 handling this MIME type.

 2. Should Lintian be continuing to recommend that people installing
*.desktop files call dh_desktop just in case, even if there are no
MimeType entries in the *.desktop files?  I've been leaning that way in
the past, but given how long it's been since dh_desktop was added and
given that it still doesn't do anything else, I wonder if this isn't
just noise.  I'm currently leaning towards removing the check for
dh_desktop in favor of only checking for update-desktop-database when
there are *.desktop files with MimeInfo unless someone tells me that's
a bad idea.

 I can see how it would be useful to recommend calling dh_desktop as
 soon as you distribute .desktop files just like it would be more useful
 if we could inject any rules in packages via cdbs or the new dh.
 However, this is really packaging style and using an extensible
 packaging style shouldn't be imposed by a checker tool like lintian;
 I'm not aware of any different dh_desktop usage which would justify
 raising a warning right now.

 Also, would we have to do more things on .desktop files, we would have
 more options to implement them without requiring dh_desktop (triggers
 come to mind).

 So not raising a lintian warning when dh_desktop isn't called on
 .desktop file would be more to my taste.

 3. Does the Shared MIME-info Database or the update-mime-info program have
anything to do with this?  I think I've convinced myself that they
don't, but I'd love confirmation from someone who works more intensely
in the desktop environment world than I.

 Not directly; they are used along this database.  The desktop file
 database only maps MIME types to .desktop files (applications really),
 and comes along a static list of applications which should be preferred
 for a MIME type (/usr/share/applications/defaults.list and friends).
 The Shared MIME Info database maps filenames and file contents patterns
 to MIME types.  These are often used together, but are distinct.

   Bye,
-- 
Loïc Minier


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



Re: Desktop standards, MIME info cache, and Lintian

2008-12-29 Thread Russ Allbery
Loïc Minier l...@dooz.org writes:

  (I have no idea why it's not mentionned anymore.)  Yes, the program is
  still used; it's in charge of generating
/usr/share/applications/mimeinfo.cache (and
  /usr/local/share/applications/mimeinfo.cache); these files may then be
  used by e.g. gio (in GLib) to map MIME types to .desktop files
  (really applications).  This can be used for example to open web
  objects with the correct application according to its MIME type, or via
  shared-mime-info + gio -- which allow mapping of a file's content or
  filename to a MIME type -- to open any file with an application
  handling this MIME type.

Thanks for the confirmation!

  I can see how it would be useful to recommend calling dh_desktop as
  soon as you distribute .desktop files just like it would be more useful
  if we could inject any rules in packages via cdbs or the new dh.
  However, this is really packaging style and using an extensible
  packaging style shouldn't be imposed by a checker tool like lintian;
  I'm not aware of any different dh_desktop usage which would justify
  raising a warning right now.

  Also, would we have to do more things on .desktop files, we would have
  more options to implement them without requiring dh_desktop (triggers
  come to mind).

  So not raising a lintian warning when dh_desktop isn't called on
  .desktop file would be more to my taste.

Okay, that matches my reasoning.  I'll remove that tag in the next version
of Lintian.  Thank you very much!

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


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



Re: Desktop standards, MIME info cache, and Lintian

2008-12-28 Thread Cyril Brulebois
Hi Russ.

Russ Allbery r...@debian.org (28/12/2008):
 I started looking today in more depth at the MIME type registration
 process for applications providing *.desktop files, dh_desktop, and
 what Lintian is currently doing (as part of addressing #488832).

With (or without, not sure) my submitter hat (Corsac mentioned it on
IRC, and I had some free time back then, so I filed the bug)…

 What I've implemented: In resolving #488832, I plan on removing that
 check and instead checking whether packages that ship *.desktop files
 containing MimeType keys call update-desktop-database in their
 postinst. This is a more direct check that verifies the actions of
 dh_desktop and will also catch packages that don't use debhelper or
 that don't have a conventional debian/rules file (such as CDBS
 packages).
 
 I think that's an improvement.

… so do I, thanks!

(and I share your questions.)

Mraw,
KiBi.


signature.asc
Description: Digital signature