[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Should ucf be of priority required?



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?

> 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.

        The tool is always performing its duties, really.  What it needs
 to do depends on state, and the environment, which you don't  take into
 account. 

>> > 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.

        No. It does not decide what ucf does. It does not decide that
 ucf actually does anything; or puts it into a RDBMS, or into a file, or
 ignores it. All it does is to make a call to ucf. ucf decides how to
 handle the call, or whether even to offer the interface.


> Well, its a fact. ucf does not need this data, the package does not need
> that data. Not even the administrator needs that data.

        True. But  when the internal staate information is discarded
 depends on ucf. It can keep the data around for historical reasons if
 it wants.

>> 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.

        And I say it does do its duties. Point me to what duties are
 failed as far as its use case actors are concerned (don't talk to me
 about internal details of the abstraction, which are none of your
 business). 

> 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 ucf gets to decide what it does with its internal state
 information. It can keep data no longer needed if it wants,  for
 historical purposes (and tomorrow, provide a log of activities -- not
 that I am promising to code that). Stay the hell out of the internal
 details of the service, and how it provides the functionality beneath
 it's API.


> 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?

        usually, ucf would be in a different part of its internal state
 diagram, and its behaviour would be different. ucf gets to decide how
 it behaves in different internal states with respect to internal state
 data.


        manoj

-- 
The system was down for backups from 5am to 10am last Saturday.
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: