Building a Perl package database (was Re: Uninstalling obsolete module files)

Michael G Schwern <[email protected]> Sat, 15 Dec 2012 14:15:24 -0800
Newsgroups gmane.comp.lang.perl.modules.module-build
Message-ID <[email protected]>
On 2012.12.15 9:20 AM, Alberto Sim=F5es wrote:
> It would be cool if a module could obsolete other module.
>=20
> For instance, I noticed that Net::DNS no longer installs Net::DNS::Doma=
in.
> This means the Domain.pm file will be hanging in the system until a ful=
l
> reinstall of the perl module tree is done.
>=20
> Just like one can specify a list of PM files in the distribution, it wo=
uld be
> cool if we could specify a list of modules that get obsolete with this
> installation, something like:
>=20
>     obsoletes_modules =3D> [ 'Net::DNS::Domain' ],
>=20
> One could maintain this information for a few releases, and the install=
 action
> would remove the Domain.pm file if it finds it.
>=20
> Thoughts on this?

There's a potential security hole in what you propose.  This allows any a=
uthor
to delete any other module partially circumventing the namespace ownershi=
p
system.  PAUSE could look at your META data and check if you have the rig=
hts
to the module you're obsoleting.

A malicious author can do this right now with some custom code.  I don't =
think
it's a serious security concern, but the extra PAUSE permission check wou=
ld be
handy.

When it comes to packaging, my first thought is always WDDD?  What Does D=
ebian
Do?  They usually do it right.

AFAIK Debian doesn't have such a thing.
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlfi=
eldslist
Closest thing they have is Conflicts.
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

Why?  They don't need it.  They already know what's installed, what packa=
ge
owns what file and can fully uninstall the old version on upgrade.  This
solves a great many problems.

We don't have that, but we should.  Imma let you finish and not hijack yo=
ur
post to talk about that.  And IMO we should continue to assume we don't h=
ave a
package database until we actually do.


--=20
Ahh email, my old friend.  Do you know that revenge is a dish that is bes=
t
served cold?  And it is very cold on the Internet!