I had a look at the experimental xemacs-21.4.11 ebuild and it wants to install around thirty elisp packages from app-xemacs. IMO the ebuild should only install the very basic xemacs with the few fundamental packages, which it cannot do without. A user may want to manage the packages himself by using Xemacs' native package management fascility or by installing the xemacs-packages-sumo package, both methods potentially providing all of the above elisp packages. I propose creating "xemacs-packages" meta-package that would install the optional elisp stuff. But the "xemacs" ebuild should provide nothing more than a bare Xemacs installation.
the original ebuild for XEmacs installed efs, xemacs-base and mule-base if you have mule in your use flags. the new setup replicates that but with packages. the large quantity of packages that get installed is due to the dependancies inherited from the XEmacs packages system. those extra packages are required to get all the benfits of those 3 packages. so this is an XEmacs problem that is currently being worked on.
Yes, I realize that efs, xemacs-base and mule-base are (almost) required for basic installation, and agree that they should be installed by the 'xemacs' ebuild or separate packages. I still don't understand how that gets inflated to including over 30 packages instead of 3. The file README.packages that comes with xemacs-21.4.12 tarball stipulates that one only needs 'efs' to get package management going, and xemacs-base is only needed because 'efs' is using it. Hence I think that we should limit the initial number of packages brought in by the xemacs ebuild (directly or indirectly) to those three (or even two, since xemacs-mule can be installed separately or as part of the sumo tarball). Actually, now that I have thought about it some more, I think that mule-base should *not* be installed by default. I understand that you are saying that you copied the inter-package dependency scheme from xemacs's internal one; but somehow I find it hard to believe that the "cookie" package is needed (directly or indirectly) for the proper function of "efs". ;^) Thanks.
Like i said above the XEmacs packages for gentoo are based on the official packages for XEmacs and the requires for those packages. i am a part of the XEmacs packages team as well as the official XEmacs guy for gentoo, If you install those packages via the XEmacs packages system including the packages they require you will get the same result as you do with installing them via gentoo portage. mule-base includes some basic functionality that is NEEDED for a mule build of XEmacs so not installing it for a mule build is shooting yourself in the foot.
Okay, maybe we should define what is the basic installation of Xemacs. I think that the basic ebuild of Xemacs should install just enough stuff for the user to be able to install other packages (at which point the user has three avenues of doing it: native package management (or even manual), packages as ebuilds, or the sumo tarball). Then we should provide enough explanation of how to do this second step. Are we in agreement on this point? If we are not, then perhaps we should discuss this in -dev or -core and get some more opinions. Then, we should answer the question: exactly what is required to achieve the above goal of the basic functionality. The Xemacs' documentation stipulates that nothing more than efs and xemacs-base. p.s. My basic problem is that I don't like a large number of packages over-writing each other's files. My chosen way of installing Xemacs packages is the sumo tarball, and I want to know that no other packages are overwriting the files, installed by the tarball. p.p.s. I am aware of your Xemacs affiliations.
Perhaps this bug can be closed? Last time I emerged xemacs, it had one dependency other than itself (app-xemacs/base) or maybe I am missing something.
Mass re-assign of really stale bugs; xemacs herd, please verify the status and close them if these issues no longer exist.
(In reply to comment #5) > Perhaps this bug can be closed? Last time I emerged xemacs, it had one dependency > other than itself (app-xemacs/base) or maybe I am missing something. I also did not find anything special wrt dependencies in the current ebuilds and most of them can be disabled via use flags. Assuming fixed, reopen if you still think there are too many dependencies.
