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!
