Re: Should ucf be of priority required?
On Sat, Dec 05, 2009 at 08:35:38PM -0600, Manoj Srivastava wrote:
> >> > I never said that. The problem are not the files owned by the package,
> >> > but the files owned by ucf, which are modified by ucfr, while not
> >> > restoring the changes if ucf is not around.
> >> Well, if ucf is not around, one should not expect the internal
> >> state of ucf to be up to date. Is this a problem?
depends on what you expect. I would expect or no lets say I wish that
purging a package removes all traces that the package where installed
in the first place, except the cases where this is inappropriate (for
example: there is a good reason not to remove logfiles on purge).
Basically this is a very common assumption for using a package
management at all, I think.
> > Yep. This is the whole point of asking this: Is this a problem for us
> > or do we simply ignore it? E.g. the fact that a package can change the
> > state of an external program, but eventually not restore it. The
> > problem with it that the change is bound to the package removed, not
> > to ucf, thats why I'm wondering at all.
> That's pretty abstract. And this generally, there might not be
> something one may say one way or the other, and have to deal with it on
> a case by case basis.
Is it? The case with ucf and $random_package is a concrete example
of leaving modified files around when purging a package that is
associated to the change. For no good reason, except technical
> In this particular case, do you see I concrete problem that I do
> not? If you think there is a concrete problem, can you explain? I
> can't see a problem here, and the ucf man page has wat I beliece to be
> the correct advice.
again, depends on what you expect. Reinstalling the package will not
cause any harm when the package is in the ucf registry, will it?
So, it doesn't have any practical effect (tough luck!), except that there
are still modified files around, when you purge the package and ucf is not around.
Considering other cases we are not yet aware of, would be abstract, but
I don't think this is.