Re: Should ucf be of priority required?
On Mon, Dec 07 2009, Joe Smith wrote:
> I suspect Patrick might be worried about a scenario like the following.
> Lets assume there is a package Foo that depends on and uses
> ucf. Further the package is the only one ucing UCF on the system.
> At some point the admin decides to remove Foo. Since there are no
> other packages that use ucf on this hypothetical system, the admin
> also chooses to remove ucf.
> The admin purges Foo, but not ucf. Later the user installs some other
> package that uses ucf.
> The net result here is that ucf may be keeping excess state related to
> package foo.
But it is not. ucf knows well that when it is reinstalled the
state information can't be trusted, it is merely historical, and takes
steps to preserve, but not trust, that data.
> Since it was not around to be alerted when Foo was purged, ucf is
> unaware that this excess data may no longer needed. Thus any state of
> ucf related to the package Foo will live on until some point when ucf
> is purged, or perhaps if Foo is reinstalled, and then re-removed and
That would have been very bad design, and a bug.
> On the other hand, had the admin purged ucf at the same time that he
> purged Foo, when ucf was reinstalled later it would start from a clean
> slate and not keep around this old state that is not terribly useful
And lose all historical data about the state of the system. I
prefer to not throw away information when it can reasonably be kept.
> Now I'm not familar enough with ucf to know if this is a real
> possibility. Perhaps ucf's design has something to prevent such a
> thing from occuring.
It is not a possibility.
> I'm not sure.
Then perhaps asking, rather than insisting on breaking
encapsulation, should be the first thing to try to do? Either read the
code, or ask first?
> It certainly sounds like a plausible way to leak disk space.
And again, ucf has a limit on the historical data that it
not really a novice in software design anymore.
Pudder's Law: Anything that begins well will end badly. (Note: The
converse of Pudder's law is not true.)
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C