On Fri, Aug 30, 2002 at 11:05:46PM +0100, Ed Avis wrote: > >It's sort of silly to require that you have a copy of the source > >code in order to uninstall a module. > > I am not sure that it is silly. It seems to be the convention to do > things this way: for example when installing a GNU package there may > be a 'make uninstall' but there is no way to automatically remove the > package without having the source code.
Then it's a silly convention. Anyway, we left the GNU tools in the dust years ago. :) > If you do want the ability to uninstall then you use a package manager > such as RPM, or such as GNU Stow, or any of the dozens of other > packaging/uninstallation systems. As has been pointed out in the past, MakeMaker & Module::Build are defacto package managers. [Along with the CPAN shells] they automate and normalize the finding of, downloading, building, testing, installing and querying of Perl modules as well as where and how they're installed. If that's not a package manager I don't know what is. Now, as to whether or not it's a *good* package manager... > The question is: should there be uninstall functionality with the > package, which risks reinventing the wheel, or should it be up to the > user to use whatever packaging tool he wishes, which risks annoying > those users who don't want to bother with extra tools. Both. The various OS distributions will always want to wrap our stuff with their package manager no matter how good we get. It's just compatibility. However, the better we get, the less work they have to do. > (It starts to get hairier when you have upgrades from one version of a > module to a later version, or configuration files which should not be > changed during such an upgrade, or files shared between two different > packages. Fortunately such issues don't usually come up with Perl > modules (so far), but they are bread and butter for programs like > rpm.) You'll probably want to look at how Debian's dpkg solves these problems, not rpm. You might want to read section 6 of the Debian FAQ "Basics of the Debian Package Management System" and go from there. http://www.debian.org/doc/FAQ/ch-pkg_basics.html > >Having a "make uninstall" target wouldn't be the canonical way to > >remove a module, simply a way to address the "Shit! I didn't mean > >to install that there!" problem. > > It needs to be decided: should there be a canonical way to remove a > module? There are few things which are canonical in Perl. There are merely things people put lots of effort into and people liked enough to make it ubiquitous. In other words: Just Do It Already > >and implement something else? Probably do it with Module::Build as > >I have no plans to do any significant changes to MakeMaker. > > If you are saying that MakeMaker will not get a fancy packlist-based > uninstaller, then there is no reason not to rip out packlists now. Or > at least quietly ignore them in new code. As Nick pointed out, MakeMaker already has a packlist based uninstaller. ExtUtils::Install::uninstall(). It even has an uninstall target which uses it, but it's deprecated. I forget why it's deprecated. If someone wants to investigate and undeprecate it I'd accept that. Otherwise, I'd rather just leave packlists as they are and extend Module::Build instead. -- Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One The truth is you suck!
