Re: Debian menu system update
* Colin Walters <walters@debian.org> [030530 19:45]:
> What do you mean "consistent concept overall"? Using the freedesktop
> standards makes things more consistent, not less.
Then please point to a documentation, how to overwrite the menus
installed with the packages as admin or other things like this.
We will need to add some way to get windowmangers and modules
to existing windowmanagers handled.
> > I think making update-menus able to parse files in dektop menu
> > specification will only cause such files beeing included without
> > inspection by newbies.
>
> Oh, right. I think we should make newbies create Debian packages using
> dd. After all, otherwise we might actually make creating Debian
> packages easier, have less maintenance burden on ourselves! We can't
> have that.
I cannot parse that.
> > There a many things, that make proper packaging of software a
> > complex matter.
>
> Making Debian packages of software should not be complex for the simple
> cases. There's just no reason for it to be.
The most of the complexity is not what and how to do things, but to see
what needs to be done. A classical menu item is easy to do and well
documented. Checking a .dektop-file, if it is good enough to be included
it not so easy, but easy to miss looking into it at all.
> > Writing this single line to get a menu-item
> > should really no problem.
>
> Writing it is just the start; it has to be translated,
If it is translated upstream and the name is usable, then there is no
problem in taking the translations. If it is not, it has to be done
anyway.
> and it's just
> another thing that has to be maintained by the Debian packager.
I strongly believe the menu is something to be maintained. Debian is
about quality and Debian is the only one to include almost any piece
of free software. We cannot let slip in whatever any upstream thinks
is the best place for its items.
> And
> moreover, it's not just a maintenance burden on the packager; everyone
> else has to learn a Debian-specific menu system, with all the drawbacks
> I already mentioned earlier.
Let me come back to my directory example. Some time ago people switching
to Debian had to learn headers are in /usr/include and nothing installed
by debian is in /opt. I did not think it was a bad things and others
following have showed it was the right way.
If there is a good way for the hirachy of the menu, there is no reason
not to adopt it.
> > using .dektop will in the long run cause masses of people learn a new
> > format and in order to get a coherent understandable system need rewrite
> > of masses of old
>
> It's the other way around; keeping our proprietary menu system forces
> administrators to learn yet another needlessly Debian-specific thing
> when using Debian.
While the "needlessly Debian-specific thing" is working, documented and
supportes the things administrators need. (Next step is abolishing
update-alternative, just another things people have to learn...)
> > The currest system works and has
> > many nice aspects of configurability and administrability,
>
> The freedesktop standard is extremely configurable, using the .menu
> files. It was designed to be so.
It was designed to cope the needs of KDE and GNOME. These are well known
to favor single-user systems, pretend nothing outside their own exists and
in general be a nightmare to administrators.
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
Reply to: