Bug#561952: developers-reference: Section 4.6.3 - please document new source package formats 3.0 (quilt) and 3.0 (native)
On Mon, 04 Jan 2010, Tommi Vainikainen wrote: Raphael Hertzog hert...@debian.org writes: Right, thanks for the reminder. I did not use your patch. You'll find attached the patch that I committed. Please review and do not hesitate to spot mistakes. Looks good, but there was one spelling mistake muliple (multiple) in the section 4.6.3 in the attached patch. Thanks, fixed. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: all or any as Dependency Qualifiers
Russ, Thanks very much for the thoughtful explanation. I'm glad that there will be a warning in the next release so that we realize it's a bad idea :) Cheers, Jonathan On Sun, Jan 3, 2010 at 11:24 PM, Russ Allbery r...@debian.org wrote: Jonathan Yu jonathan.i...@gmail.com writes: This is a stupid idea, and I don't know any case where it might make sense to do it, but it has occurred to me that Policy doesn't mention anything explicitly forbidding it, as far as I can tell. Lintian allows it through without warning about it. Presumably this is because nobody has ever done something like this before. In the current Policy (a cursory glance at Chapter 7), it's unclear whether it is possible to do something like: Depends: some-library [!all] or: Depends: some-library [all] Sorry about the (very long) delay in replying to this message. I had it queued up to look at it further and then lost track of it. Policy currently says: The brackets enclose a list of Debian architecture names separated by whitespace. Exclamation marks may be prepended to each of the names. all and any are not Debian architecture names. Those are defined in 11.1. They're special values for the Architecture field. I'm just not sure about the expected behaviour when the special keywords (all, any, source) are used. They should be rejected. Indeed, Lintian doesn't warn about this right now except for source, nor does it warn about mixing exclamation points and non-exclamation points in the same [] section. I'll fix that for the next release. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: does /var/games have to be deleted on purge? (if it's empty..)
Hi, 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 signature.asc Description: This is a digitally signed message part.
Re: does /var/games have to be deleted on purge? (if it's empty..)
Holger Levsen hol...@layer-acht.org writes: 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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: does /var/games have to be deleted on purge? (if it's empty..)
Hi, 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 signature.asc Description: This is a digitally signed message part.
Re: does /var/games have to be deleted on purge? (if it's empty..)
On Mon, 04 Jan 2010, Holger Levsen wrote: On Montag, 4. Januar 2010, Russ Allbery wrote: * 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. For this, you actually should be using --force-confmiss. Basically see my answers to previous two arguments. IMHO purging should do what it's designed to do. This entire discussion is about what purging should be designed to do. There are lots of examples of data which is has significant user contribution but is coupled to varying degrees to a package (or even multiple packages). Consider data in /var/www, for example, or collections of mysql databases created by versions of mysql which have been partially replaced by subsequent versions of mysql. Or ldap databases which were created by openldap, but are now being used by some other ldap replacement (or some custom scripts). Purge should clean up detrius, but there is always a balance between completely cleaning out the detrius and destroying user data which may be wanted. Don Armstrong -- Everyone has to die. And in a hundred years nobody's going to inquire just how most people died. The best thing is to do it in the way that strikes your fancy most. -- Kenzaburō Ōe _Silent Cry_ p5 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: does /var/games have to be deleted on purge? (if it's empty..)
Don Armstrong d...@debian.org writes: On Mon, 04 Jan 2010, Holger Levsen wrote: On Montag, 4. Januar 2010, Russ Allbery wrote: * 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. For this, you actually should be using --force-confmiss. Is there some way to pass that flag through apt-get or aptitude? By the time I've resorted to aptitude download to get the *.deb to run dpkg on, it's usually easier to have just done aptitude purge, aptitude install. I bring this up not because it's the only method (I know it's not), but because it's really common, and I even use it myself because I don't usually remember other methods or they take a bit more thought. I've seen lots of Debian users do this, people who are going to be rather surprised if that suddenly causes their data to be removed, and I'm not sure we can reach all of those people to communicate this significant of a behavior change. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
