On Sun, Dec 06 2009, Patrick Schoenfeld wrote:
> Hello,
>
> 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.
You have expressed an opinion, no, a wish, that something
happens one way. What you have not demonstrated a concrete harm that
happens in this case when your wish is not granted.
>> > 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
> inability.
What harm comes of it? Youhave already removed ucf at this
point. What is the sue case you are presenting that suffers?
Saying I wish this not to happen, and thus when it happens, that
is the harm is circular logic, not a concrete example.
>
>> 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?
If ucf is not around, it does not make a difference one way or
the other. Indeed, without ucf being around, the code to manipulate
ucf internal data structures is not around either.
Your argument seems to be that if a package called ucf in order
to have ucf change its internal state, ucf should be kept around to
make changes to the internal state, willy nilly? What would that solve,
apart from granting your wish?
> 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.
These files belong to ucf. When ucf is purged, those files would
be removed too.
> Considering other cases we are not yet aware of, would be abstract, but
> I don't think this is.
So it is a hypothetical harm, with no concrete examples you can
think of.
manoj
--
Complex system: One with real problems and imaginary profits.
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
