Bug#460504: dh_desktop/dh_icons madness - Debian

This is a discussion on Bug#460504: dh_desktop/dh_icons madness - Debian ; 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 ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Bug#460504: dh_desktop/dh_icons madness

  1. 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-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. 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 haveto 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. Perhapsthere
    > 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.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBHieDNrSla4ddfhTMRAnSWAJ91LGbN6ddJSQJtllKPm4 GVyISjawCeK3qo
    06soqcUeuC+zGGod1OUU/b0=
    =Ia5B
    -----END PGP SIGNATURE-----


  3. 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-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. 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 doany
    > 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.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBHifeMrSla4ddfhTMRAlWmAKComnGAC+tnhhawkSLGrf s1ASK3cwCfbrtu
    Eo7G2USrtKZGmbqj9QW6rYg=
    =fAxC
    -----END PGP SIGNATURE-----


  5. 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-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. 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.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBHigTIrSla4ddfhTMRAtNxAJ93NlQXNaAGfv5IjNsJVP 6trXGuLACgpnin
    R9Wt9Cf80Fx2oDq0UsrBuIg=
    =kNhF
    -----END PGP SIGNATURE-----


  7. Re: Bug#460504: dh_desktop/dh_icons madness

    On 2008-01-13, Josselin Mouette 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

  8. Re: 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.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBHihnfrSla4ddfhTMRAmCyAKC7QammYGSgBknSFnpZgm iZVWHCeACgsCjU
    PDe49kgAlp6i+9BS9bhx3hk=
    =RX1R
    -----END PGP SIGNATURE-----


  9. Re: Bug#460504: dh_desktop/dh_icons madness

    On 2008-01-13, Josselin Mouette 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

  10. Re: 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 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.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBHiiDhrSla4ddfhTMRArewAKDnvK88qhWSzcisC5G48F OdS4TQNgCeIDjE
    5Nf8SZz2lbvPy5GGQNOHp8o=
    =adXt
    -----END PGP SIGNATURE-----


  11. Re: Bug#460504: dh_desktop/dh_icons madness

    On Sun, Jan 13, 2008, Peter Eisentraut wrote:
    > 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.


    Theoretically, this is supposed to only affect all packages shipping
    icons in particular directories; for example, you have to coordinate
    addition of cache handling snippets for all packages shipping files
    below /usr/share/icons/hicolor otherwise you'll be missing some icons
    when you install a package without the snippets.

    > On a technical level, the best approach would appear to be
    > implementing some sort of global dpkg postinst and postrm hooks.


    Yes, "triggers"; I think these were not available at the time of the
    first implementations; I did object to the current implementation for
    many reasons -- but not to use triggers -- but as I didn't produce any
    alternative code, the proposed implementation was merged and is now
    what we rely on. I'd very much like if someone would provide a simpler
    implementation, which I imagine could be based on triggers.

    --
    Loc Minier


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

  12. Re: Bug#460504: dh_desktop/dh_icons madness

    Le dimanche 13 janvier 2008 22:02 +0100, Loc Minier a crit :
    > > On a technical level, the best approach would appear to be
    > > implementing some sort of global dpkg postinst and postrm hooks.

    >
    > Yes, "triggers"; I think these were not available at the time of the
    > first implementations; I did object to the current implementation for
    > many reasons -- but not to use triggers -- but as I didn't produce any
    > alternative code, the proposed implementation was merged and is now
    > what we rely on. I'd very much like if someone would provide a simpler
    > implementation, which I imagine could be based on triggers.


    As soon as triggers are available, the current implementation of both
    update-desktop-database and update-icon-caches (as well as scrollkeeper)
    can be trivially made to use them.

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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBHjH+erSla4ddfhTMRAsvPAKDIqL1LDSJXfBAfEZFCr1 cHtIVRmwCgk77a
    DEmSKxwoAYUa32U9OaHeiYQ=
    =dq4F
    -----END PGP SIGNATURE-----


  13. Bug#460504: marked as done (dh_desktop/dh_icons madness)


    Your message dated Sat, 20 Sep 2008 12:39:57 +0200
    with message-id <200809201239.58133.holger@layer-acht.org>
    and subject line not a bug
    has caused the Debian Bug report #460504,
    regarding dh_desktop/dh_icons madness
    to be marked as done.

    This means that you claim that the problem has been dealt with.
    If this is not the case it is now your responsibility to reopen the
    Bug report if necessary, and/or fix the problem forthwith.

    (NB: If you are a system administrator and have no idea what this
    message is talking about, this may indicate a serious mail system
    misconfiguration somewhere. Please contact owner@bugs.debian.org
    immediately.)


    --
    460504: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460504
    Debian Bug Tracking System
    Contact owner@bugs.debian.org with problems


+ Reply to Thread