FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 12-06-2009, 11:17 AM
Patrick Schoenfeld
 
Default Should ucf be of priority required?

On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote:
> There's no reason that ucf *should* fall under either of these rules; so
> even if ucf /didn't/ work the way it does, the right solution here would be
> to fix it so that it did, not to add it to Essential.

Makes sense. But how do you fix a package to do what its supposed to do,
when it isn't installed anymore? This is a corner-case and I wonder
weither we should handle it and how we should handle it. Making ucf
is essential is one idea, getting the functionality merged back into
an utility which is already essential would be another.

Regards,
Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-06-2009, 11:26 AM
Patrick Schoenfeld
 
Default Should ucf be of priority required?

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.

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

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

Considering other cases we are not yet aware of, would be abstract, but
I don't think this is.

Best Regards,
Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-06-2009, 11:30 AM
Patrick Schoenfeld
 
Default Should ucf be of priority required?

Hi,

On Sat, Dec 05, 2009 at 11:43:28AM -0600, Manoj Srivastava wrote:
> This is where things break down. ucf --purge does not do what
> you think it does, it by no means removes the configuration files. You
> remove the configuration files, not ucf.

It seems that I expressed myself unclear, because several people (like
you) read from my sentences that I expect ucf to remove the
configuration files. This is not the case. I perfectly understand what
ucf --purge does.

Actually the point is what a random package should do if it is beeing
purged in order to undo what it has done on installation in the
corner-case when ucf is beeing removed.

Regards,
Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-06-2009, 11:35 AM
Patrick Schoenfeld
 
Default Should ucf be of priority required?

On Sun, Dec 06, 2009 at 06:12:24AM +0100, Norbert Preining wrote:
> Not wanting to start another flame war, but ...
>
> On Sa, 05 Dez 2009, Patrick Schoenfeld wrote:
> > The crux is the last point. For a good reason postrm must not require
> > tools it depends on to be around when removing the package itself.
>
> making dpkg policy compliant would help, too, then we removed package
> can expect dependcies to be present.

Seems like this would be tough work for dpkg to handle

Apart from this (Warning: What comes next is not really thought about):
Would it be an option to let dpkg support the purge action in its prerm
script and run ucf --purge therein? Is this possible at all?

Regards,
Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-06-2009, 02:22 PM
Manoj Srivastava
 
Default Should ucf be of priority required?

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 <srivasta@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-06-2009, 02:26 PM
Manoj Srivastava
 
Default Should ucf be of priority required?

On Sun, Dec 06 2009, Norbert Preining wrote:

> On So, 06 Dez 2009, Manoj Srivastava wrote:
>> So, policy does not require dependencies to be around at least
>> during purge.
>
> Ah yes of course, sorry. I was referring to the remove phase, where it
> is also not present, although policy states it.

Are you sure this is the case being discussed? The thread is
dealing with ucf -p, which is called when you are purging your package.

,----[ Manual page ucf(1) ]
| -p, --purge
| Removes all vestiges of the file from the state hashfile. This is
| required to allow a package to be reinstalled after it is purged;
| since otherwise, the real configuration file is removed, but it
| remains in the hash file; and on reinstall no action is taken,
| since the md5sum of the new file matches that in the hashfile.
| In short, remember to use this option in the postrm for every
| configuration file managed by ucf when the package is being
| purged (assuming ucf itself exists). Note: ucf does not actually
| touch the file on disk in this operation, so any file removals
| are still the responsibility of the calling package.
`----

So, I see no indication that dpkg is not following policy, based
on this thread. What makes you think it is?

manoj
--
We are using Linux daily to UP our productivity - so UP yours! (Adapted
from Pat Paulsen by Joe Sloan)
Manoj Srivastava <srivasta@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-06-2009, 02:28 PM
Manoj Srivastava
 
Default Should ucf be of priority required?

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

manoj
--
"It's a dog-eat-dog world out there, and I'm wearing Milkbone
underwear." Norm, from _Cheers_
Manoj Srivastava <srivasta@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-06-2009, 02:30 PM
Manoj Srivastava
 
Default Should ucf be of priority required?

On Sun, Dec 06 2009, Patrick Schoenfeld wrote:


> Actually the point is what a random package should do if it is beeing
> purged in order to undo what it has done on installation in the
> corner-case when ucf is beeing removed.

Remove your files, and make a best effort attempt to call other
utilities to clean up indirect mods, iff they exist.

Which is what is happening here. If you want tohter things to
happen, you have to make a case for why (a case that goes beyond I wish
it were so).

manoj
--
To be, or what? Sylvester Stallone
Manoj Srivastava <srivasta@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-06-2009, 02:37 PM
Marc Haber
 
Default Should ucf be of priority required?

On Sat, 5 Dec 2009 21:48:44 +0100, Michael Banck <mbanck@debian.org>
wrote:
>On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote:
>> the right solution here would be to fix it so that it did, not to add
>> it to Essential.
>
>On a side note, I thought the right solution was to integrate the ucf
>functionality into dpkg. Any update on this, or was this just wishful
>thinking on my part?

I would go the contrary way: ditch dpkg conffile handling and have it
handled from without dpkg. That way, one has the chance of hooking
into the process for local modifications.

For example, I have been looking for a way to tamper with package a's
dpkg-conffiles from package b, which would be very helpful for local
sysadmin work (such as rolling out local configuration via a package).

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-06-2009, 03:00 PM
Tollef Fog Heen
 
Default Should ucf be of priority required?

]] Patrick Schoenfeld

Hi,

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

So you would expect a package to be marked as uninstalled and not purged
in the dpkg status file when it's purged? And for packages that does
not come from Packages file to be completely dropped?

If not, what am I missing?

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org