Re: Splitting of XEmacs21 elisp packages
James Troup <email@example.com> writes:
> Daniel Schepler <firstname.lastname@example.org> writes:
>> Browsing through the wishlist bugs on xemacs21-packages, I've seen
>> several requests for the ability to remove parts of the XEmacs
>> support code, either to save disk space or to replace them with
>> newer upstream versions.
> I really don't buy the saving disk space argument; anyone seriously
> short of disk space isn't going to be running xemacs. The replacement
> argument also seems entirely frivilous unless xemacs is wildly
> different from emacs (e.g. with emacs, you can happily install a newer
> gnus even tho an older copy is also included with emacs).
>> Also, upstream often releases updates to just one or a few of these
>> modules. By splitting the packages, it would become easier to keep
>> them up to date without requiring users to download 18 MB every week
>> or two.
> They don't have to download it if they don't want to and the "every
> week or two" argument seems a bit, err, contrived given the actual
> history of Debian uploads.
My point was that currently the packages aren't very "up to date", and
uploads could be more frequent if this splitting made it less
expensive to update the packages, both for the users and for the
maintainer. (Note that I'm not the current maintainer of
xemacs21-packages. I sent a message to email@example.com about
my packages a couple days ago but haven't gotten a response yet.)
>> Hmm, on the other hand it _is_ a lot of packages, which could be
>> confusing to users.
> And hugely unlikely to get out of NEW, TBH. There's just no
> reasonable excuse for having so many tiny packages.
Then I'm genuinely curious what's different about the situation with
phpgroupware and usermin/webmin.
Honestly, though, I'm getting less and less convinced myself that this
is a good idea.
Daniel Schepler "Please don't disillusion me. I
firstname.lastname@example.org haven't had breakfast yet."
-- Orson Scott Card