Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Uninstalling obsolete module files
2 views
Skip to first unread message
Alberto Simões
Dec 15, 2012, 12:20:47 PM12/15/12
to module...@perl.org
Hello
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?
Cheers,
ambs
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?
Cheers,
ambs
Leon Timmermans
Dec 15, 2012, 5:25:14 PM12/15/12
to Michael G Schwern, module...@perl.org
On Sat, Dec 15, 2012 at 11:15 PM, Michael G Schwern <sch...@pobox.com> wrote:
> 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.
We have packlists, so we can easily map a distribution to its files.
The reverse mapping can be generated from this, though this is
relatively expensive.
> 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.
We have packlists, so we can easily map a distribution to its files.
The reverse mapping can be generated from this, though this is
relatively expensive.
Alberto Simões
Dec 16, 2012, 6:12:06 AM12/16/12
to module...@perl.org
On 15/12/12 23:00, Michael G Schwern wrote:
> On 2012.12.15 2:25 PM, Leon Timmermans wrote:
>>> 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.
>>
>> We have packlists, so we can easily map a distribution to its files.
>> The reverse mapping can be generated from this, though this is
>> relatively expensive.
>
> Packlists are unreliable and have design problems. Some perl distributions
>>> 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.
>>
>> We have packlists, so we can easily map a distribution to its files.
>> The reverse mapping can be generated from this, though this is
>> relatively expensive.
>
> (Debian) disable them. I wouldn't build anything around them.
>
> PS Sorry, I didn't mean to change the thread subject. I wound up writing my
> own post.
Your proposal makes sense but is more difficult (takes more time).
But it solves the issue, and other issues.
Alberto
0 new messages