As per bug #21037 which was never truly resolved, I want to question Mailman's install location in Gentoo. First and foremost, this mess has arisen because Mailman installs it's binaries, libraries and data, by default, to the same location. No one knew what to do with this, so it has (finally) been left at the default location; /usr/local/mailman, which is somewhat rediculous. Pretty much every application out there installs to /usr/local by default, but they aren't there now because the Gentoo (and any other distro's) package management system changes the install target to /usr (for binaries at least). /usr/local is for hand-installed packages. This bug is therefore to discuss what needs to be done to split Mailman up, to allow it to be installed in sane locations. I have Mailman installed by portage on my server, so I tried copying the bin directory, with permissions, to somewhere entirely different. All of the executables ran fine. I don't think that's enough to separate it into /usr though, because there exists a file paths.pyc, which has been compiled by python after the install: # equery b /usr/local/mailman/bin/paths.py net-mail/mailman-2.1.5-r4 (/usr/local/mailman/bin/paths.py) # equery b /usr/local/mailman/bin/paths.pyc <none found> I'm not sure when this file is generated, but I'm pretty sure it could be forced by portage as part of the install process. The rest should be controllable by the various configure directives, --bindir, - -libdir, etc. Lastly, thought needs to go into what happens to existing installs. Does the ebuild honour existing locations, only doing fresh installs to the new locations? I don't think it could successfully move the existing install while Mailman's running, so maybe fail if mailman is running, and alert the user? Comments are very welcome. I plan to work on an improved ebuild, but I don't want to waste my time if a dev is going to tell me it's going to stay where it is. Reproducible: Always Steps to Reproduce:
+1 on this; just nothing else in portage touches /usr/local
*** This bug has been marked as a duplicate of 84708 ***
