Re: New DFSG-compliant emacs packages
Peter Galbraith <p.galbraith@globetrotter.net> writes:
> David Kastrup <dak@gnu.org> wrote:
>
>> Peter S Galbraith <p.galbraith@globetrotter.net> writes:
>>
>> > David Kastrup <dak@gnu.org> wrote:
>> >
>> >> [...] since
>> >> nobody can understand or work with the broken mess the Debian
>> >> Emacs package policies provide.
>> >>
>> >> I think you'll be hard put to find any maintainer or developer
>> >> of an Emacs or XEmacs application who would not rather use a
>> >> self-compiled Emacs than the Debian contraptions.
>> >
>> > Ouch, such spite...
>>
>> That is no spite. Ask on the developer lists.
>
> "broken mess" and "Debian contraptions" sound spiteful to me.
Well, they stop the package system of XEmacs from working as intended
concerning package load order, nobody from the Emacs or XEmacs
developers understands or uses them, and they set up a load of
complicated rules for the sole purpose of using the same source files
_without_ symlinks in all ports, scattering source and compiled Lisp
files in different locations and places in the load order. The
diagnostic M-x list-load-path-shadows RET intended for debugging
broken systems, goes wild on Debian. It is not sensibly possible to
install, say, your own up-to-date version of AUCTeX from a source ball
and install it into a local tree, in particular if there is a system
AUCTeX present already. This works neither on Emacs, nor on XEmacs.
So it is broken. None of the active Emacs or XEmacs developers admits
to understanding the system. So it is a mess. The rules go over
pages and have nothing to do with the normal way packages or Lisp code
are usually installed in Emacs. So it is a contraption.
I am calling a spade a spade here, and nothing else.
>> I subscribed to this list when I had a need of understanding the
>> Emacs package policies. While I did not succeed in this endeavor,
>> there are still decisions made here where I think my input not
>> completely amiss. If you know for certain that Debian developers
>> won't listen to input, I might consider unsubscribing again.
>
> I doubt anyone would respond favorably to "broken mess" and
> "contraptions". I doubt you would on the AUCTeX list either.
We call some code worse names on the AUCTeX list.
> But I would think your input would be well received if it were more
> constructive.
I explain how to diagnose the problems, I explain that the load-path
must not be split among compiled and source Elisp files. I make
proposals to do this rather with symlinks.
This input gets ignored. It is not for the first time on this list.
I am used to it. But I find it offensive that in spite of my input
being ignored, people say it is not there, or not constructive.
> But this is a Debian policy issue,
The topic right now was not a Debian policy, but the Debian Emacs
packaging policy. And I mentioned the Debian Emacs packaging policy
just to make clear that the target of the Debian Emacs packages are
_not_ Emacs developers: those don't actually use the Debian Emacs
packages.
The people affected by the Debian policies are pretty much only users
without Emacs projects of their own. Because the developers will
(because of the Emacs packaging policies) not make use of precompiled
Emacs versions, anyhow.
> not an Debian Emacs packaging policy issue, so there not much you
> can do about it. Moving the whole thing to non-free means removing
> Emacs from Debian, since non-free isn't part of Debian. I
> understand that the line is unclear to many users.
If Emacs does not meet the standards of Debian, yes, this would be the
thing to do.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Reply to: