triggers wishlist
"Michael Biebl" <biebl@debian.org> wrote in message
news:47F2FC19.5020001@debian.org... I guess Joss is right here. triggers tell you *if* something has changed >(in a subdirectory), but not *what*. Remember, that we have to call gtk-update-icon-cache /usr/share/icons/$subdir for the directory that has changed. Michael How expensive is running gtk-update-ican-cache? I mean, it would be easy enough to have a script run that runs "gtk-update-icon-cache /usr/share/icons/$subdir" for each of the subdirectories. Then the /usr/share/icons trigger would just run that script. -- To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
triggers wishlist
On mer, 2008-04-02 at 21:07 -0400, Joe Smith wrote:
> How expensive is running gtk-update-ican-cache? I mean, it would be easy > enough to have a script run > that runs "gtk-update-icon-cache /usr/share/icons/$subdir" for each of the > subdirectories. Then the /usr/share/icons > trigger would just run that script. It takes a few seconds for a big icon theme on a fast machine, but as it must read all icons in the directories, it can easily turn out slower. -- .'`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile. |
triggers wishlist
Josselin Mouette writes ("Re: triggers wishlist"):
> On mer, 2008-04-02 at 21:07 -0400, Joe Smith wrote: > > How expensive is running gtk-update-ican-cache? I mean, it would be easy > > enough to have a script run > > that runs "gtk-update-icon-cache /usr/share/icons/$subdir" for each of the > > subdirectories. Then the /usr/share/icons > > trigger would just run that script. > > It takes a few seconds for a big icon theme on a fast machine, but as it > must read all icons in the directories, it can easily turn out slower. Would a timestamp check help ? You can have several triggers of course but the triggers system is not designed to have very many of them. If you expect to have a dozen icons subdirs eventually then a trigger for each one would be overkill. Also, if you have only one trigger you can know that dpkg won't call your postinst for triggers more than once unnecessaarily. Ian. -- To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
triggers wishlist
On Mon, Mar 31, 2008 at 10:31:36AM -0500, Steve Greenland wrote:
> On 30-Mar-08, 15:25 (CDT), Joey Hess <joeyh@debian.org> wrote: > > dpkg in experimental supports triggers now, and in many cases trigger > > support can be added to packages without creating a hard dependency on > > a new version of dpkg. > > > > Things I want to see use triggers, in approximate priority order: > > The various emacsen-related packages seem to cause multiple re-compiles > during a single install run. It's not terribly slow, but it's sort of > annoying. [cc'ing debian-emacsen so people is aware of this thread] I am not sure triggers are the right tool here, byte-recompilation can be enabled by any of package-with-lisp or emacs-package upgrade/install. emacs packages have no way of knowing at build time which packages-with-lisp are to be installed, so I am not sure which would be the right triggers. However, if there is a clean way of using triggers for this I would be happy to be corrected. On the other hand the main problem is, as others have pointed out, due to the noise produced by the lack of a -no-init-file opton. Same byte-compilation is done twice as much, and sometimes is done just once. In the meantime I have been experimenting with a different approach. I think the multiple byte-compilation problem can also be addressed with minor changes in current behavior, something as shown below in some sort of pseudo-code. '+' stands for the additional stuff ---------------------------------------------------------------------- emacsen-remove: (Run from prerm) remove elcdir and its contents emacsen-install: (Run from postinst) set -e + if -e elcdir/done + skip + else create elcdir Byte-compile files to elc dir + touch elcdir/done + fi --------------------------------------------------------------------- So if byte-compilation succeeds a 'done' file is touched and its presence can be used as a proof of that, so byte-compilation is not retried. On package or emacs upgrade the elcdir is removed, so byte-complation is tried again. -- Agustin -- To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
triggers wishlist
On Sun, Mar 30, 2008 at 04:25:15PM -0400, Joey Hess wrote:
> Things I want to see use triggers, in approximate priority order: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=133917 (man-db) can at long last be fixed with a trigger. I had a tested patch for this a little while back, which I'll dust off and upload. -- Colin Watson [cjwatson@debian.org] -- To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
triggers wishlist
Anyone out there?
On Tue, Apr 1, 2008 at 9:27 AM, Tshepang Lekhonkhobe <tshepang@gmail.com> wrote: > On Mon, Mar 31, 2008 at 10:28 AM, Josselin Mouette <joss@debian.org> wrote: > > On dim, 2008-03-30 at 16:25 -0400, Joey Hess wrote: > > > Things I want to see use triggers, in approximate priority order: > > > > > > - scrollkeeper > > > > It will probably be deprecated soon, so I don't think it is necessary to > > put effort into it. > > Would rarian-compat be the replacement? If so, what's the delay? -- my place on the web: floss-and-misc.blogspot.com -- To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
| All times are GMT. The time now is 01:39 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.