Achim Gratz <strom...@nexgo.de> writes: > Phillip Lord writes: >> I think there's only a few problems, actually. package.el initialization >> is all or nothing at the moment, and is disabled on emacs -q. Neither of >> these would make sense if we wanted in built packages. > > My opinion is that unless package.el adds explicit support for > system-level packetization decisions (i.e. for admins or distributions) > it's not going to gain widespread support from that small, but important > set of folks.
I think it mostly has this, in the sense that you can add packages into admin installation locations. Although, this are disabled with emacs -Q. > Of course the user will then have to be able to override these like > deactivation of packages, installing different versions, etc. Different versions you can do. Deactivation at the moment, no, although I guess you could delete the autoloads. > Before long it also needs to be able to cope with different package > archives simultaneously especially when those have incompatible > numbering schemes. That one would be a bit harder, although you could add support for package repositories to add their own numbering scheme by installating a package. > >> It's not strictly necessary, though. The current idea is to not to use >> packages but to, essentially, move the lisp of packages in ELPA into >> place in the build. package.el need not be involved then. > > Yes I know. Which is in essence prolonging the current state of affairs > as far as the users are concerned. If it gets things moving into the > right direction I'll be glad. I just had hoped for some more general > (some would say radical) solution. Some did say radical, unfortunately. Still, you give me encouragement. I may complete my solution after all. Perhaps combined with a completely repackaged Emacs core. Phil
