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!