FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-13-2008, 08:21 AM
Peter Eisentraut
 
Default Bug#460504: dh_desktop/dh_icons madness

Package: general
Severity: normal

For a while now some folks have been going around asking various package
maintainers to inject dh_icons and/or dh_desktop calls into the package build
rules. The basic argument appears to be that your package needs to do this so
that my desktop environment will work correctly. I don't think this approach
has correct and sustainable principles. And what is more, if some random third
packages or user environments dictate what other, unrelated packages have to do
to function with them, we will in practice never reach a state where everything
works. Furthermore, if other desktop environments come up with their own
variants of icon caching of MIME file registration (since these are supposedly
Free Desktop standards) or perhaps completely new file registration
requirements, we will have an unmaintainable mess of competing implementations
of registration scripts, and thousands of packages stuck in a transition
somewhere between all of them.

It seems to me that, in principle, if some third package or user environment
wants something to be done for its own functional benefit, it should be its own
responsibility to arrange that, instead of bothering thousands of other
packages with it. This appears to be the only robust and maintainable
approach. On a technical level, the best approach would appear to be
implementing some sort of global dpkg postinst and postrm hooks. Perhaps there
are other ideas, but the current approach needs to stop; it won't work.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-13-2008, 08:58 AM
Josselin Mouette
 
Default Bug#460504: dh_desktop/dh_icons madness

On dim, 2008-01-13 at 10:21 +0100, Peter Eisentraut wrote:
> For a while now some folks have been going around asking various package
> maintainers to inject dh_icons and/or dh_desktop calls into the package build
> rules. The basic argument appears to be that your package needs to do this so
> that my desktop environment will work correctly. I don't think this approach
> has correct and sustainable principles.

Debian has always been about integration. Don’t you register your
documentation with doc-base so that your application integrates with
centralized documentation systems? Don’t you register your fonts with
defoma so that applications using it can actually see the fonts?

The same goes for desktop environments. You need to register your icons
so that they are correctly cached (icon loading is one of the biggest
performance issues on desktops), and to register your desktop files so
that the MIME registry works.

> And what is more, if some random third
> packages or user environments dictate what other, unrelated packages have to do
> to function with them, we will in practice never reach a state where everything
> works.

It is not a random user environment. It is the accepted standard for the
three main desktops we are shipping.

> Furthermore, if other desktop environments come up with their own
> variants of icon caching of MIME file registration (since these are supposedly
> Free Desktop standards) or perhaps completely new file registration
> requirements, we will have an unmaintainable mess of competing implementations
> of registration scripts, and thousands of packages stuck in a transition
> somewhere between all of them.

But we are not talking about other desktop environments. If you were
asked to use dh_desktop, it is because your application *does* ship
Freedesktop .desktop files. If you were asked to use dh_icons, your
package *does* include icons in the Freedesktop directory hierarchy.

Furthermore, the update-mime-database and update-icon-caches commands
have very simple APIs which mean we can replace them easily with other
implementations if someone wants to design them.

> It seems to me that, in principle, if some third package or user environment
> wants something to be done for its own functional benefit, it should be its own
> responsibility to arrange that, instead of bothering thousands of other
> packages with it.

Is it the desktop environment’s or the package’s own functional benefit
to have the application launched when you click on a file of the related
type, or to have a visible icon? This is merely a philosophical
question.

> This appears to be the only robust and maintainable
> approach. On a technical level, the best approach would appear to be
> implementing some sort of global dpkg postinst and postrm hooks. Perhaps there
> are other ideas, but the current approach needs to stop; it won't work.

I thought dpkg triggers had been sufficiently advertised, but it seems
the mails haven’t reached the (deep ?) place you are living in.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 
Old 01-13-2008, 10:15 AM
Peter Eisentraut
 
Default Bug#460504: dh_desktop/dh_icons madness

Josselin Mouette wrote:
> Debian has always been about integration. Don’t you register your
> documentation with doc-base so that your application integrates with
> centralized documentation systems?

I'm glad you bring up this comparison, but this is different. If someone
neglects to do doc-base registration, his package's documentation won't be
usable in a nice way. That directly affects the functionality of that
package. If someone doesn't do dh_icons or dh_desktop registration, nothing
changes for that package. It affects only users of whatever environment it
is that appears to require this.

> It is not a random user environment. It is the accepted standard for the
> three main desktops we are shipping.

I assume you are talking about GNOME, Xfce, and KDE here. KDE doesn't do any
of this, so have doubts about the "accepted standard". It seems silly to
request all KDE-related packages to jump through hoops so they work with
GNOME.

> Is it the desktop environment’s or the package’s own functional benefit
> to have the application launched when you click on a file of the related
> type, or to have a visible icon? This is merely a philosophical
> question.

It is to the desktop environment's benefit. The package will work fine in
other environments. To pick a concrete example (bug #460449), if a GNOME
user clicks on a kdissert file and things don't work, while they work just
fine in KDE, then that is GNOME's problem, not kdissert's.

> I thought dpkg triggers had been sufficiently advertised, but it seems
> the mails haven’t reached the (deep ?) place you are living in.

They indeed haven't, but since they appear to have reached the (shallow ?)
place you are living in, why not use them?



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-13-2008, 10:35 AM
Josselin Mouette
 
Default Bug#460504: dh_desktop/dh_icons madness

On dim, 2008-01-13 at 12:15 +0100, Peter Eisentraut wrote:
> Josselin Mouette wrote:
> > Debian has always been about integration. Don’t you register your
> > documentation with doc-base so that your application integrates with
> > centralized documentation systems?
>
> I'm glad you bring up this comparison, but this is different. If someone
> neglects to do doc-base registration, his package's documentation won't be
> usable in a nice way. That directly affects the functionality of that
> package. If someone doesn't do dh_icons or dh_desktop registration, nothing
> changes for that package. It affects only users of whatever environment it
> is that appears to require this.

You are completely wrong on this topic. If you don’t use dh_icons, the
icons shipped in your package won’t be available even to the application
itself. This is caused by a broken design for icon caches; because of
this design, icon caches are currently disabled. But when all packages
have been ported to update the cache, icons shipped in packages not
doing it won’t be available all (whether the application uses Qt or
GTK).

> > It is not a random user environment. It is the accepted standard for the
> > three main desktops we are shipping.
>
> I assume you are talking about GNOME, Xfce, and KDE here. KDE doesn't do any
> of this, so have doubts about the "accepted standard". It seems silly to
> request all KDE-related packages to jump through hoops so they work with
> GNOME.

KDE already uses the freedesktop standard for the menus. If it doesn’t
use it for the MIME registry as well, I would be very surprised if
upstream didn’t have at least plans to do that.

> It is to the desktop environment's benefit. The package will work fine in
> other environments. To pick a concrete example (bug #460449), if a GNOME
> user clicks on a kdissert file and things don't work, while they work just
> fine in KDE, then that is GNOME's problem, not kdissert's.

In fact I am very surprised KDE doesn’t need the desktop database to be
up-to-date. Scanning all desktop files at runtime is deadly slow, so
even in this case it is a bad idea not to update the cache. Which is why
this is also probably affecting KDE users.

> > I thought dpkg triggers had been sufficiently advertised, but it seems
> > the mails haven’t reached the (deep ?) place you are living in.
>
> They indeed haven't, but since they appear to have reached the (shallow ?)
> place you are living in, why not use them?

If you had read them, you would also know this feature isn’t available
yet.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 
Old 01-13-2008, 11:12 AM
Peter Eisentraut
 
Default Bug#460504: dh_desktop/dh_icons madness

Josselin Mouette wrote:
> You are completely wrong on this topic. If you don’t use dh_icons, the
> icons shipped in your package won’t be available even to the application
> itself.

I don't claim to know the technical details of this, but I don't have
update-icon-caches installed and I have never had a missing icon. So again I
suspect that this is an issue particular to some other environment. Which
was my point.

> > > I thought dpkg triggers had been sufficiently advertised, but it seems
> > > the mails haven’t reached the (deep ?) place you are living in.
> >
> > They indeed haven't, but since they appear to have reached the (shallow
> > ?) place you are living in, why not use them?
>
> If you had read them, you would also know this feature isn’t available
> yet.

So the transitive closure of this discussion is that you are just idly
rambling. Thank you for your time.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-13-2008, 11:32 AM
Josselin Mouette
 
Default Bug#460504: dh_desktop/dh_icons madness

On dim, 2008-01-13 at 13:12 +0100, Peter Eisentraut wrote:
> Josselin Mouette wrote:
> > You are completely wrong on this topic. If you don’t use dh_icons, the
> > icons shipped in your package won’t be available even to the application
> > itself.
>
> I don't claim to know the technical details of this, but I don't have
> update-icon-caches installed and I have never had a missing icon. So again I
> suspect that this is an issue particular to some other environment. Which
> was my point.

Nope, this works because you don’t have an icon cache. But if it gets
enabled (it often happens when you install something by hand or use an
Ubuntu package, and it *will* be the default in the future), icons not
in the cache won’t be visible.

> > If you had read them, you would also know this feature isn’t available
> > yet.
>
> So the transitive closure of this discussion is that you are just idly
> rambling. Thank you for your time.

No, the conclusion is that you are grumbling about something that is
already underway, and that you are knowingly preventing your package to
integrate correctly without any justification but your own laziness.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 
Old 01-13-2008, 12:49 PM
Sune Vuorela
 
Default Bug#460504: dh_desktop/dh_icons madness

On 2008-01-13, Josselin Mouette <joss@debian.org> wrote:
> You are completely wrong on this topic. If you don=E2=80=99t use dh_icons, =
> the
> icons shipped in your package won=E2=80=99t be available even to the applic=
> ation
> itself. This is caused by a broken design for icon caches; because of
> this design, icon caches are currently disabled. But when all packages
> have been ported to update the cache, icons shipped in packages not
> doing it won=E2=80=99t be available all (whether the application uses Qt or
> GTK).

Please get out of your extreme gnomecentered world.
KDE isn't using the icon caches.
KDE4 is using its own pr user dynamic icon caching mechanism.

>> request all KDE-related packages to jump through hoops so they work with=20
>> GNOME.
>
> KDE already uses the freedesktop standard for the menus. If it doesn=E2=80=
>=99t
> use it for the MIME registry as well, I would be very surprised if
> upstream didn=E2=80=99t have at least plans to do that.

KDE is jumping thru the hoops for us so we don't have to do it in the
packages.

> In fact I am very surprised KDE doesn=E2=80=99t need the desktop database t=
> o be
> up-to-date. Scanning all desktop files at runtime is deadly slow, so
> even in this case it is a bad idea not to update the cache. Which is why
> this is also probably affecting KDE users.

It takes around 2 seconds and is done as needed in KDE to update its
database and is a pr user thingy also run in the background on login and
on first launch of a kde program.

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-13-2008, 01:02 PM
Josselin Mouette
 
Default Bug#460504: dh_desktop/dh_icons madness

On dim, 2008-01-13 at 13:49 +0000, Sune Vuorela wrote:
> Please get out of your extreme gnomecentered world.
> KDE isn't using the icon caches.

I wonder why the KDE developers are participating in freedesktop if they
don’t use the specifications they helped writing.

> KDE4 is using its own pr user dynamic icon caching mechanism.

> KDE is jumping thru the hoops for us so we don't have to do it in the
> packages.

> It takes around 2 seconds and is done as needed in KDE to update its
> database and is a pr user thingy also run in the background on login and
> on first launch of a kde program.

Building caches at the user level for system stuff doesn’t sound like a
good design. Fontconfig stepped back from it some time ago, and I hope
KDE will do the same.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 
Old 01-13-2008, 01:23 PM
Sune Vuorela
 
Default Bug#460504: dh_desktop/dh_icons madness

On 2008-01-13, Josselin Mouette <joss@debian.org> wrote:
> Building caches at the user level for system stuff doesn=E2=80=99t sound li=
> ke a
> good design. Fontconfig stepped back from it some time ago, and I hope
> KDE will do the same.

How to cache contents of peoples ~/.kde at system level?

It is very wide spread among kde users to actually configure and change
ones system. I know this might sound strange to gnome people, but it is
actually the case.

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-13-2008, 01:32 PM
Josselin Mouette
 
Default Bug#460504: dh_desktop/dh_icons madness

On dim, 2008-01-13 at 14:23 +0000, Sune Vuorela wrote:
> On 2008-01-13, Josselin Mouette <joss@debian.org> wrote:
> > Building caches at the user level for system stuff doesn=E2=80=99t sound li=
> > ke a
> > good design. Fontconfig stepped back from it some time ago, and I hope
> > KDE will do the same.
>
> How to cache contents of peoples ~/.kde at system level?

You cache system stuff at the system level, and user stuff at the user
level. Is that so complicated?

> It is very wide spread among kde users to actually configure and change
> ones system. I know this might sound strange to gnome people, but it is
> actually the case.

If all you are interested in is sarcasm, I’m afraid this discussion
isn’t leading anywhere. (As it didn’t start from anywhere either, this
would be logical, though.)

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

Thread Tools




All times are GMT. The time now is 07:03 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org