On 2012.12.15 9:20 AM, Alberto Simões wrote:
It would be cool if a module could obsolete other module.

For instance, I noticed that Net::DNS no longer installs Net::DNS::Domain.
This means the Domain.pm file will be hanging in the system until a full
reinstall of the perl module tree is done.

Just like one can specify a list of PM files in the distribution, it would be
cool if we could specify a list of modules that get obsolete with this
installation, something like:

obsoletes_modules => [ 'Net::DNS::Domain' ],

One could maintain this information for a few releases, and the install action
would remove the Domain.pm file if it finds it.

Thoughts on this?
There's a potential security hole in what you propose. This allows any author
to delete any other module partially circumventing the namespace ownership
system. PAUSE could look at your META data and check if you have the rights
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 would be

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

AFAIK Debian doesn't have such a thing.
Closest thing they have is Conflicts.

Why? They don't need it. They already know what's installed, what package
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 your
post to talk about that. And IMO we should continue to assume we don't have a
package database until we actually do.

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

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 6 | next ›
Discussion Overview
groupmodule-build @
postedDec 15, '12 at 5:21p
activeDec 17, '12 at 12:18a



site design / logo © 2018 Grokbase