Re: Should ucf be of priority required?
On Mon, Dec 07 2009, Patrick Schoenfeld wrote:
> Hi,
>
> (uhm.. I really hate it, if I can't hold the promises to myself I made;
> in this case: not further discussing it, but still here is
> another answer)
>
> On Mon, Dec 07, 2009 at 10:04:14AM -0600, Manoj Srivastava wrote:
>> On Mon, Dec 07 2009, Patrick Schoenfeld wrote:
>>
>> > 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.
>>
>> Again, you make an assertion, without any basis for it. Why is
>> it better, apart from the fact you seem to think it would be? What use
>> case is being negatively impacted?
>
> Yes, I do make an assertion. But not "without any basis". Its just not a
> basis that you accept.
>
> All boils down to the points where we disagree the most:
> - I consider data that is used *nowhere* as garbage. You think its not
> garbage, because you could use it some time in the future.
Right.
> - I consider ucf just a tool doing a certain duty on behalf of the
> package requesting it.
Yup. The task is to ask the user about how they want to handle
what is done to files when the package is being upgraded.
> For me this assumes that data created during this task belongs to
> the package that requested the creation of the data in the first
> place.
That breaks abstraction and encapsulation.
> And it includes providing an interface that does exactly what
> is it told to do.
Sorry. This is not the software paradigm you are looking for. In
keeping with modular (and object oriented) design, ucf provides certain
facilities. It keeps internal state, but that is opaque to the user.
> For you the data belongs to ucf and it can do with it whatever it
> wants to do. So if a postrm requested to purge the file from the
> database it would also be okay, if ucf didn't do that.
Nope. No other package gets to muck around with the internal
structures and data for any utility, and that includes files hidden
from the application. The API is provided for a purpose: use it, and do
not break encapsulation by delving into internal details of the
implementation.
> Apart from this you made clear that you don't want to discuss your
> software design, because "its not my business". Good to know.
No, I meant it is not the business of any application that uses
the interfaces that ucf provides.
I'll be happy to discuss the design. I'll be even happier to
support any use cases you can bring up and advocate.
> I won't go further trying to change what I think is wrong. You as the
> ucf maintainer decided that collecting garbage is okay, because
> its not garbage in your opinion. Most other people agreed to that or
> didn't comment at all (including those persons who agree with me).
> It doesn't matter anyway. Its been a corner case from the beginning,
> a seldom one additionally. There is work on-going or at least planned
> to merge ucf functionality into dpkg, which is the better solution
> IMHO anyway and will probably fix my "problem".
I was not aware that dpkg was going to expand and work with non
conffiles: most of the work is for providing ucf-like handling of
conffiles, not for configuration files, unless I am misreading
something.
> You won't change my mind. I will not change your mind.
> So to save us from discussing the topic to death, let us just agree to
> disagree, ok?
That's a cop out. It is, as you said, my package, and I will
listen to people pointing out what are flaws, but I reserve the
right to also say why it is not a flaw.
As I see it, internal state of a utility is its own, and the
very reason it provides an API is to abstract the functionality (so
internal implementation can change), encapsulate internal state and
data (so other applications and users don't have to worry about how
things are implemented).
If any supported use cases are broken, that would be a bug. I do
not see there is indeed a bug.
manoj
--
The hearing ear is always found close to the speaking tongue, a custom
whereof the memory of man runneth not howsomever to the contrary, nohow.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: