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 handy. 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. http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlfieldslist 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 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!
