does /var/games have to be deleted on purge? (if it's empty..)
Holger Levsen
while testing the archive with piuparts I found a failure reported by
piuparts, that after purge /var/games existed on the system while it wasnt
there before installing+purging the package.
See http://piuparts.debian.org/squeeze/fail/slashem-common_0.0.7E7F3-1.3.log
(at the end..)
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARGAMESVARIABLEGAMEDATA says
that /var/games is an optional directory, which must be present if the
corresponding subsystem (here: a game) is present.
Thus I would conclude that it has to be removed on purge if there are no other
games installed. Right? Or should I make piuparts ignore the /var/games
directory if present after purge?
regards,
Holger
http://piuparts.debian.org/squeeze/fail/armagetronad-dedicated_0.2.8.2.1-10.log
is definitly buggy, as it not only leaves /var/games on the system but
also /var/games/armagetronad :-)
Russ Allbery
> while testing the archive with piuparts I found a failure reported by
> piuparts, that after purge /var/games existed on the system while it
> wasnt there before installing+purging the package.
>
> See http://piuparts.debian.org/squeeze/fail/slashem-common_0.0.7E7F3-1.3.log
> (at the end..)
I'm curious why it wasn't removed. /var/games is normally shipped in each
of the packages that provides files in /var/games, so dpkg would normally
remove it automatically once the last game was removed from the system.
It seems to have left it unowned, which implies to me that either some
package created it in a maintainer script rather than just including the
directory in the deb or you're running into the bug that I ran into with
openafs where dpkg lost track of the owner of a directory (I can't find
the bug number at the moment).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-q...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sven Joachim
> Holger Levsen <hol...@layer-acht.org> writes:
>
>> while testing the archive with piuparts I found a failure reported by
>> piuparts, that after purge /var/games existed on the system while it
>> wasnt there before installing+purging the package.
>>
>> See http://piuparts.debian.org/squeeze/fail/slashem-common_0.0.7E7F3-1.3.log
>> (at the end..)
>
> I'm curious why it wasn't removed. /var/games is normally shipped in each
> of the packages that provides files in /var/games, so dpkg would normally
> remove it automatically once the last game was removed from the system.
But not if the game actually writes highscore files there. Those are
only removed on purge, at which point dpkg has already forgotten that
/var/games belonged to the package.
> It seems to have left it unowned, which implies to me that either some
> package created it in a maintainer script rather than just including the
> directory in the deb or you're running into the bug that I ran into with
> openafs where dpkg lost track of the owner of a directory (I can't find
> the bug number at the moment).
For /var/games and subdirectories this does not really hold due to the
additional files written there at runtime.
Sven
Russ Allbery
> On 2009-04-06 19:59 +0200, Russ Allbery wrote:
>> I'm curious why it wasn't removed. /var/games is normally shipped in
>> each of the packages that provides files in /var/games, so dpkg would
>> normally remove it automatically once the last game was removed from
>> the system.
> But not if the game actually writes highscore files there. Those are
> only removed on purge, at which point dpkg has already forgotten that
> /var/games belonged to the package.
Oh, aha, yes. That explains it.
We'd then have a similar problem with any other /var directory that holds
files mostly created at runtime and only deleted on purge, such as
/var/log, except that the rest are always in existence.
I don't see much real benefit in going out of our way to remove /var/games
and it looks like it would be a bit annoying (at the least, require adding
purge code to all games that put files in /var/games that would usually
never be triggered). My inclination would be to say that this behavior is
fine and perhaps we should officially bless it somewhere.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Holger Levsen
On Montag, 6. April 2009, Russ Allbery wrote:
> We'd then have a similar problem with any other /var directory that holds
> files mostly created at runtime and only deleted on purge, such as
> /var/log, except that the rest are always in existence.
According to the FHS the other 4 directories in the same category
as /var/games are /var/account, /var/crash, /var/mail and /var/yp.
> I don't see much real benefit in going out of our way to remove /var/games
less cruft on disk, better overview when doing "ls /var", but yeah... that's
not really much :)
> and it looks like it would be a bit annoying (at the least, require adding
> purge code to all games that put files in /var/games that would usually
> never be triggered).
Sounds like a job for debhelper/cdbs to me...
> My inclination would be to say that this behavior is
> fine and perhaps we should officially bless it somewhere.
I'd appreciate that, I like to follow documented procedures when adding
checks/ignores to piuparts and then run it on the archive ;)
regards,
Holger
Paul Wise
> I don't see much real benefit in going out of our way to remove /var/games
> and it looks like it would be a bit annoying (at the least, require adding
> purge code to all games that put files in /var/games that would usually
> never be triggered). My inclination would be to say that this behavior is
> fine and perhaps we should officially bless it somewhere.
A single rmdir in every game using /var/games isn't that hard,
especially since they have to remove the files from there.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Holger Levsen
On Dienstag, 7. April 2009, Paul Wise wrote:
> A single rmdir in every game using /var/games isn't that hard,
> especially since they have to remove the files from there.
I agree and plan to file RC bugs on this.
(There have been 24781 binary packages been successfully tested in sid and
squeeze atm, 369 have failures, of which eleven packages keep /var/games
around, of which 4 also keep other files in /var/games/* - seven more RC bugs
sound reasonable to me. Plus potentially a few more in packages not tested.)
Or is RC too much? Or fine now?
regards,
Holger
Julien Cristau
> Or is RC too much? Or fine now?
Anything > normal would be too much IMO.
Cheers,
Julien
Bill Allombert
Unless policy is changed to make clear that /var/games can be removed
at any time, and thus that package cannot just ship /var/games in the
deb and expect it to be available when running the postinst, or at any
latter time, I have to object with this bug reports because this
introduces a race condition.
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
Holger Levsen
On Mittwoch, 8. April 2009, Bill Allombert wrote:
> Unless policy is changed to make clear that /var/games can be removed
> at any time, and thus that package cannot just ship /var/games in the
> deb and expect it to be available when running the postinst, or at any
> latter time, I have to object with this bug reports because this
> introduces a race condition.
I dont understand, can you please explain what race condition you mean?
regards,
Holger
P.S.: Thanks for all your CC:s but I'm subscribed to -qa@ :-)
Paul Wise
> On Mittwoch, 8. April 2009, Bill Allombert wrote:
>> Unless policy is changed to make clear that /var/games can be removed
>> at any time, and thus that package cannot just ship /var/games in the
>> deb and expect it to be available when running the postinst, or at any
>> latter time, I have to object with this bug reports because this
>> introduces a race condition.
>
> I dont understand, can you please explain what race condition you mean?
How about this:
Game a gets installed and ships /var/games
Game b gets installed and ships /var/games
Game a gets purged and removes /var/games
User starts game b and gets a high score
Game b tries to save the high score but fails because /var/games doesn't exist
--
bye,
pabs
http://wiki.debian.org/PaulWise
http://synfig.org/User:PaulWise
http://bonedaddy.net/pabs3/
Holger Levsen
On Mittwoch, 8. April 2009, Paul Wise wrote:
> How about this:
>
> Game a gets installed and ships /var/games
> Game b gets installed and ships /var/games
> Game a gets purged and removes /var/games
> User starts game b and gets a high score
> Game b tries to save the high score but fails because /var/games doesn't
> exist
Uhm, I thought it was obvious that /var/games may only be deleted if it's
empty...
regards,
Holger
Julien Cristau
And it is empty until you try and play game b. Which might be after
purging game a, which removed /var/games. Hilarity ensues. So either
game a must not remove /var/games, or game b must ship
with /var/games/.b-placeholder to make sure that /var/games isn't empty
while b is installed. The former seems saner to me.
Cheers,
Julien
Holger Levsen
On Mittwoch, 8. April 2009, Adeodato Simó wrote:
> Additionally, what happens if package A and B both ship an empty
> /var/games (they both write their score files directly there, rather
> than a subdirectory), get both installed, then B gets purged and its
> postinst removes /var/games, and then A runs and tries to write to
> /var/games a score file, but the directory does no longer exist nor has
> the game write permission to create it. Is there or is there going to be
> a policy mandating that packages should not ship /var/games without
> shipping /var/games/<name>?
Isn't the right approach for these packages to register the files they rely on
in /var/games/ with dpkg?
regards,
Holger
Andrew McMillan
But Paul is describing a situation where it is empty (Game b installed
it, but has not yet written a high score into it), but the simple rmdir
logic will delete it. ==> very bad.
Cheers,
Andrew.
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You have no real enemies.
------------------------------------------------------------------------
Holger Levsen
On Montag, 6. April 2009, Russ Allbery wrote:
> I don't see much real benefit in going out of our way to remove /var/games
> and it looks like it would be a bit annoying (at the least, require adding
> purge code to all games that put files in /var/games that would usually
> never be triggered). My inclination would be to say that this behavior is
> fine and perhaps we should officially bless it somewhere.
I've come to agree with this. :-) Now, where to bless it?
regards,
Holger
Goswin von Brederlow
And I think there is your problem.
If the package had removed all files then dpkg would have removed the
dir automatically.
MfG
Goswin
Holger Levsen
x-debbugs-cc: debi...@lists.debian.org, debian...@lists.debian.org
"9.1.1 File system Structure" has a list of exceptions from the FHS, so it
seems it should go there.
regards,
Holger, who will now make piuparts not complain about /var/games existing
after package removal..
Russ Allbery
to-process queue.
I was going to look to see where to patch Policy to talk about this, but
after looking through Policy to see where one would put that information,
I couldn't find anywhere in Policy that specifies which files should be
removed on package purge. There are specific requirements around
configuration files and log files, but other than that Policy seems to
take for granted that anyone reading it understands what purging means.
Should we add a section to Policy somewhere that explains the package
states and what the requirements of a package are around preserving or
removing its data other than log files and configuration files on purge?
If so, that would be the relevant place to talk about whether or not
directories like /var/games should be removed when empty (and similarly
/var/games/package, /var/lib/package, etc.).
Holger Levsen
On Montag, 4. Januar 2010, Russ Allbery wrote:
> >> and what the requirements of a package are around preserving or
> >> removing its data other than log files and configuration files on
> >> purge? If so, that would be the relevant place to talk about whether
> >> or not directories like /var/games should be removed when empty (and
> >> similarly /var/games/package, /var/lib/package, etc.).
> >
> > I think policy is currently vague about this since perhaps such
> > a decision ought to be made on a case by case basis? I can certainly
> > see the difference in preservation of data and state information for a
> > RDBMS package as being different from that of a game which is different
> > still from a clock program. Can we be certain that the distribution is
> > best served by a one size fits all policy here?
> That's a good point. Maybe we should defer this to devref. The Kerberos
> KDC prompts, for instance, and I think the LDAP server does as well, since
> losing that data can be a significant problem.
Well, I think about changing my mind here. In the past, piuparts has indeed
ignored eg the non-removal of the ldap database on purge. But now I wonder,
why should this be done. Unix has a tradition to allow you to shot into your
foot and if you do a purge of a package, then IMHO a purge should do what a
purge should do. If you dont have backups and do purge, you might loose some
important data. But thats the same with "rm -rf /" or such.
So what should be the criteria for a package to behave differently on purge?
> But I would expect most
> games to delete their high score files and whatnot on purge.
Actually I'd expect a purge to have the same results for any package.
> We do seem to be pseudo-enforcing some rules around this via bug filings
> based on puiparts and the puiparts results presented on the QA pages.
> Those rules should probably at least be documented in the devref.
Absolutly.
cheers,
Holger
Russ Allbery
> Well, I think about changing my mind here. In the past, piuparts has
> indeed ignored eg the non-removal of the ldap database on purge. But now
> I wonder, why should this be done. Unix has a tradition to allow you to
> shot into your foot and if you do a purge of a package, then IMHO a
> purge should do what a purge should do. If you dont have backups and do
> purge, you might loose some important data. But thats the same with "rm
> -rf /" or such.
> So what should be the criteria for a package to behave differently on
> purge?
There are several arguments that say that such data shouldn't be deleted
on purge. I don't know how persuasive they are.
* The data is not created by the package, in the sense that it's not
created automatically by package installation. It's created by the
user's use of the package and is the user's data. It's not clear that
the mysql-server package, for instance, owns all the data in the default
database location and has the right to be purging it.
* It's sometimes necessary to purge a package and reinstall it to fix some
weird problem, or if not necessary at least expedient. For example, if
one accidentally deletes a configuration file, one of the faster ways to
get the original configuration file shipped with the package back is to
purge and reinstall the package. It saves unpacking the package
somewhere and manually copying out the configuration file. If purging
the package deletes databases, this removes that tactic as an option.
* Whether it makes sense given Debian semantics or not, users just don't
expect removing packages to, from their perspective, destroy data.
Other distributions don't seem to do this.
Holger Levsen
On Montag, 4. Januar 2010, Russ Allbery wrote:
> There are several arguments that say that such data shouldn't be deleted
> on purge. I don't know how persuasive they are.
I'll answer them in reverse order :-)
> * Whether it makes sense given Debian semantics or not, users just don't
> expect removing packages to, from their perspective, destroy data.
> Other distributions don't seem to do this.
We are talking about "purging", not "removal", thus I consider this argument
invalid. I expect "purge" to remove all traces of a package from the system.
> * It's sometimes necessary to purge a package and reinstall it to fix some
> weird problem, or if not necessary at least expedient. For example, if
> one accidentally deletes a configuration file, one of the faster ways to
> get the original configuration file shipped with the package back is to
> purge and reinstall the package. It saves unpacking the package
> somewhere and manually copying out the configuration file. If purging
> the package deletes databases, this removes that tactic as an option.
Having a working backup+restore in place is probably a way better tactic :-) I
don't see how such a "workaround" should justify keeping cruft on millions of
properly administrated systems.
> * The data is not created by the package, in the sense that it's not
> created automatically by package installation. It's created by the
> user's use of the package and is the user's data. It's not clear that
> the mysql-server package, for instance, owns all the data in the default
> database location and has the right to be purging it.
Basically see my answers to previous two arguments. IMHO purging should do
what it's designed to do. If a package has data worth saving, IMHO one
shouldnt use purge or use a backup.
regards,
Holger
Joerg Jaspert
>> * Whether it makes sense given Debian semantics or not, users just don't
>> expect removing packages to, from their perspective, destroy data.
>> Other distributions don't seem to do this.
> We are talking about "purging", not "removal", thus I consider this argument
> invalid. I expect "purge" to remove all traces of a package from the system.
So when I purge OpenOffice.org from my system it should then delete all
the documents created with it? They are about the same category: Created
with the software packaged here, but not related to it otherwise, its my
data.
--
bye, Joerg
Dessen NOC erklaerte uns aber, dass das Mailproblem nicht an ihnen liegen
koennte der ihr Router habe gar keinen Port 25. Der habe nur 16 Ports.
Also kann Mails nichts mit Port 25 zu tun haben.
-- Ulli Horlacher in <a38sqm$16csas$1...@ID-124594.news.dfncis.de>
Bernhard R. Link
> >> * Whether it makes sense given Debian semantics or not, users just don't
> >> expect removing packages to, from their perspective, destroy data.
> >> Other distributions don't seem to do this.
> > We are talking about "purging", not "removal", thus I consider this argument
> > invalid. I expect "purge" to remove all traces of a package from the system.
>
> So when I purge OpenOffice.org from my system it should then delete all
> the documents created with it? They are about the same category: Created
> with the software packaged here, but not related to it otherwise, its my
> data.
Your data in in $HOME. Purging should not change there anything. But I
totally expect it to remove all system wide settings of Openoffice like
global printer settings and all modifications to system directories
not done by myself (where "done by myself" can include doing by the
program as safe-as, but only when I control the location and not if the
program does it and especially not if it does not even show me where it
happens).
On other words: as a quick test: if I only use a program as user and
purge the package and my $HOME (and perhaps /tmp by reboot), there
should be nothing left and especially when I reinstall it everything
should be as after the first installation.
Hochachtungsvoll,
Bernhard R. Link