On Sun, Dec 06 2009, Patrick Schoenfeld wrote:
> On Sun, Dec 06, 2009 at 09:28:11AM -0600, Manoj Srivastava wrote:
>> On Sun, Dec 06 2009, Patrick Schoenfeld wrote:
>>
>> > On Sat, Dec 05, 2009 at 11:44:39AM -0600, Manoj Srivastava wrote:
>> >> Making a package essential in order to avoid a if clause in
>> >> postinsts is very likely too frivolous a reason to pass muster, yes.
>> >
>> > I do not want to avoid the if-clause. I want to avoid leaving modified
>> > files around when removing a package, that modified them (indirectly)
>> > in the first place.
>>
>> 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.
>
>> What is the use case that will present an actual bad thing happening,
>> apart from your wish that modified files for packages no longer
>> installed but not purged do not remain on the system?
>
> Why are you talking about modified files to remain on the system?
These file belongs to ucf, so they live on while ucf is not
purged.
> I'm not sure you've got the point.
I, on the other hand, _know_ you are not getting it.
> To make it more clear:
> - I'm _not_ saying that ucf database has to removed, when its removed
> but not purged.
Cool.
> - I'm not talking about the configuration files of package xyz itself.
> Its clearly the job of the postrm to remove those files and this can
> happen properly.
Sure.
> - I'm not saying that apart from the configuration files any file needs
> to be *removed* from the system (your statement "your wish... files
> ... do not remain on the system" makes me think you imply that)
OK
> 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.
> 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.
> 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. If ucf does something wrong with it,
point it out, and file a bug.
> 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
anyone's business but ucf's. If purging ucf left garbage on the system
it would be a bug. This is not.
> Shouldn't we make a case, why its ok to have things in our manpages,
> such as dpkg(1) which are not true?
> 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?
> Otherwise how would your argumentation be different from saying
> its okay to leave configuration backup files around when uninstalling?
Bullshit. If ucf left state files around after purging, youmight
have some grounds to say that.
> The package did not install/create them, dpkg did it. What harm is it
> causing to the user? What bad thing would actually happen?
> Thats obvious not a good line to follow and if we'd do it would be in
> contrast to how Debian solutions in the past seeked to get near
> perfection.
I think you are very mistaken.
manoj
--
* SynrG notes that the number of configuration questions to answer in
sendmail is NON-TRIVIAL -- Seen on #Debian
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
