Re: Should ucf be of priority required?
On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote:
> >> In this particular case, what is the harm befalling the user?
> >
> > Well, I don't think that making an Operating System is just about
> > keeping harm away from our users.
>
> But it is a tenet of software design that to change something
> that is working, you have to have some justification beyond I wish
> things were different.
Making the software better, in this case. But this is quiet abstract in
this case, because this is not changing the design of a specific
tool, its about making the tool *always* perform its duties.
> I, on the other hand, _know_ you are not getting it.
Oh, fine. Leads us to a new level on our discussion.
> > All I'm talking about is: The package that is beeing purged created data
> > during its installation. If it is beeing purged, it should remove this
> > data unless there is a good reason to keep it.
>
> No it did not. The data is all internal to ucf, the package has
> no idea what the data is -- and ucf can change it internally in any
> way it wants, and the package will not be able to do anything about it.
>
> You see, this is called, CS, abstraction.
>
> The package calls ucf, and sends it a message. ucf does
> something about it.
Right. Which is a perfectly fine form of abstraction.
> > In this case there is not even almost a reason to keep the data.
>
> The package that calls ucf does not get to decide this.
No, thats wrong. The package that calls ucf does already decide this,
in the moment it gets purged and calls out to ucf to let it remove
this data, because its not used anymore. The usual case if ucf is
installed.
> > It has no use on a fresh installation of the package (and in fact it
> > must not, because the package has been purged). It has no use without
> > reinstalling the package (contrary to logfiles for example).
> > Basically its garbage.
>
> Not your call to make.
Well, its a fact. ucf does not need this data, the package does not need
that data. Not even the administrator needs that data.
> If ucf does something wrong with it,
> point it out, and file a bug.
I never said that ucf does something wrong. I said that it does not
have the chance to do its duties.
> > So under this aspect I do not see how you can argue that I would need
> > to make a case why this should not happen. Shouldn't it be the other
> > way round? Shouldn't we make a case why we should or can leave
> > *garbage* on the users system when *purging* the package who created
> > that garbage?
>
> Internal state information of icf is not garbage. It is not
Right. Its not garbage as long as it is a state information. It isn't
anymore when the package which created it, is purged, because there
is nothing ucf has to act on anymore.
> > Just to rememember:
> > purge The package is selected to be purged (i.e. we want to remove
> > everything, even configuration files).
>
> Bingo. These files do not belong to the package. They belong to
> ucf. Why is that so hard to understand?
Ah, so we get to the point that you've never spoken out but wanted to
make me understand. Now I know, why you think that you know that I
haven't gotten it.
Well, in this point we simply disagree. The data in question is not
needed by ucf at this point. In fact ucf would never have needed this
data, if the package wasn't installed in the first place. And even since
it has been installed the data has more relevance to the package itself,
because ucf is just a tool to aid the maintainer scripts in getting a
job done.
And the fact that purging a package, which uses ucf, usually would
remove the data from the ucf registry as well weakens your point.
If it would belong to ucf why bother with removing it at all?
> I think you are very mistaken.
I could say the same from you. Thats how it is, if opinions differ.
But I come to the conclusion that its not worth discussing it anymore.
Its a minimal issue and we will not reach a consense. Other people are not
involved in the discussion anymore, so EOD for me.
Regards,
Patrick
Reply to: