Re: xemacs and xemacs-sumo changes for FE6 (and some general elisp packaging stuff)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2006-09-05 at 00:05 +0100, Jonathan Underwood wrote:

> I think these packages would be much more sensibly named something
> like xemacs-sumo-base and xemacs-sumo-extras or somesuch - both should
> have sumo in the name. A package called xemacs-packages to Joe User
> might imply "install all xemacs packages that are available" i.e. some
> sort of meta package. sumo should definately be in the name.

Well, I disagree mildly; what is currently shipped doesn't quite match
what upstream includes in their sumos -- jde is pruned altogether, mew
and skk removed and provided by other implementations in FE, mule-ucs is
not always shipped, Sun will probably go away in the next revision --
and if the package would be split in two, it'd deviate even further.

FWIW, there's also some slight movement towards the "xemacs-packages"
name upstream, there are some xemacs-all-*packages symlinks in the
download dirs, and I think all non-RH-derivative distros have moved on
to use other names than the sumo.

Anyway, I don't insist getting rid of the "sumo" word.

> > Second part of the above plan is that the main xemacs package will no
> > longer have a dependency to xemacs-packages (ex-sumo, due to the build
> > dep loop above); it will have a dependency on xemacs-packages-base only.
>
> Why is even this dependency necessary?

I don't remember hearing about anyone who uses XEmacs without any lisp
packages installed (minimally xemacs-base and mule-base), and I'm not
sure if that's even supposed to actually work.

Dropping the dependency would however open some interesting
possibilities -- eg. could drop xemacs-nox *and* sanely keep the lisp
packages in their own noarch SRPM without splitting.  I'll experiment
with this.

> Does upstream xemacs really require xemacs-sumo to build?

No.

> Also, please strip out the source .el files into separate packages, as
> is done with emacs.

Sure, -el and -info subpackages will remain, similar to how they're now.

--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers

--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly

[Index of Archives]     [Fedora Users]     [Fedora Development]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux