Bug#241333: Mandate UTF-8 for changelog files
On Sat, Jul 05, 2008 at 06:40:38PM -0700, Russ Allbery wrote: diff --git a/policy.sgml b/policy.sgml index 24c9072..219664d 100644 --- a/policy.sgml +++ b/policy.sgml @@ -273,6 +273,32 @@ /p /sect + sect id=definitions + headingDefinitions/heading + + p + The following terms are used in this Policy Manual: + taglist + tagASCII/tag + item + The character encoding specified by ANSI X3.4-1986 and its + predecessor standards, referred to in MIME as US-ASCII, and + corresponding to an encoding in eight bits per character of + the first 128 url id=http://www.unicode.org/; + name=Unicode characters, with the eighth bit always zero. + /item + tagUTF-8/tag + item + The transformation format (sometimes called encoding) of + url id=http://www.unicode.org/; name=Unicode defined by + url id=http://www.rfc-editor.org/rfc/rfc3629.txt; + name=RFC 3629. UTF-8 has the useful property of having + ASCII as a subset, so any text encoded in ASCII is trivially + also valid UTF-8. + /item + /taglist + /p + /sect /chapt @@ -1473,10 +1499,6 @@ /p p - -/p - -p The format of the filedebian/changelog/file allows the package building tools to discover which version of the package is being built and find out other release-specific information. @@ -1582,6 +1604,10 @@ /p p + The entire changelog must be encoded in UTF-8. + /p + + p For more information on placement of the changelog files within binary packages, please see ref id=changelogs. /p @@ -9822,36 +9848,6 @@ install-info --quiet --remove /usr/share/info/foobar.info See ref id=dpkgchangelog. /p - p - It is recommended that the entire changelog be encoded in the - url id=http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2279.html; name=UTF-8 - encoding of - url id=http://www.unicode.org/; - name=Unicode.footnote - p - I think it is fairly obvious that we need to - eventually transition to UTF-8 for our package - infrastructure; it is really the only sane char-set in - an international environment. Now, we can't switch to - using UTF-8 for package control fields and the like - until dpkg has better support, but one thing we can - start doing today is requesting that Debian changelogs - are UTF-8 encoded. At some point in time, we can start - requiring them to do so. - /p - p - Checking for non-UTF8 characters in a changelog is - trivial. Dump the file through - exampleiconv -f utf-8 -t ucs-4/example - discard the output, and check the return - value. If there are any characters in the stream - which are invalid UTF-8 sequences, iconv will exit - with an error code; and this will be the case for the - vast majority of other character sets. - /p - /footnote - /p - sect2headingDefining alternative changelog formats /heading Seconded. Kurt signature.asc Description: Digital signature
Bug#416450: [PROPOSAL] New option in DEB_BUILD_OPTIONS to avoid running test-suites
On Sat, 05 Jul 2008, Russ Allbery wrote: Here's a slightly modified version of Guillem's patch that makes fewer assumptions about the structure of the debian/rules file in the example and doesn't refer to a non-mandatory target (install). Seconds? Seconded. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ signature.asc Description: Digital signature
Bug#473019: debian-policy: clarification needed for local builtin exception for /bin/sh
On Sat, 05 Jul 2008, Russ Allbery wrote: I suggest that Policy be amended to require that local a b c=delta e scope variables a, b, c, and e as local, and assign the string delta to the local c. Here is a proposed patch that implements Clint's suggestion. Seconds? Seconded. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ signature.asc Description: Digital signature
Bug#470994: mail_spool default mode is 0660
On Sat, Jul 05, 2008 at 04:26:25PM -0700, Russ Allbery wrote: Okay, given that I see no rationale for the sentence Mailboxes must be writable by group mail., I'm reassigning this to debian-policy. Here is a proposed change to loosen this requirement. Please comment. One concern that I have with allowing either permission scheme is that if an MUA needs to recreate the spool file, how should it know what permissions to use? I guess we should grep the sources of a few MUAs (and MDAs) to see what they do. In the meantime, the new phrasing is still much better than the current text :) - Mailboxes are generally mode 660 - ttvaruser/var:mail/tt unless the system - administrator has chosen otherwise. A MUA may remove a - mailbox (unless it has nonstandard permissions) in which - case the MTA or another MUA must recreate it if needed. - Mailboxes must be writable by group mail. + Mailboxes are generally either owned by varuser/var and mode + 600 or owned by ttvaruser/var:mail/tt and mode 660 + unless the system administrator has chosen otherwise I guess that the point of that run-on sentence is the understanding that packages should not go out of their way to prevent such sysadmin changes, so it would make sense to add a full stop after the two options and write a proper new sentence about that. + footnote + There are two traditional permission schemes for mail spools: + mode 600 with all mail delivery done by processes running as + the destination user, or mode 660 and owned by group mail with + mail delivery done by a process running as a system user in + group mail. Historically, Debian required mode 660 mail + spools to enable the latter model, but that model has become + increasingly uncommon and principal of least privilege Just a spelling fix - s/principal/the principle/ -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#143941: Mandate UTF-8 for control files
On Sat, Jul 05, 2008 at 03:27:12PM -0700, Russ Allbery wrote: This transition is already complete in the archive, so this change catches Policy up with current practice. The new paragraph would go into Policy 5.1 (Syntax of control files). Seconds? diff --git a/policy.sgml b/policy.sgml index 24c9072..0f9fbdc 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2344,6 +2344,9 @@ Package: libc6 would mean a new paragraph. /p + p + All control files must be encoded in UTF-8. + /p /sect sect id=sourcecontrolfiles Seconded. Kurt signature.asc Description: Digital signature
Bug#483418: Not limit dpkg-divert to install but valid also for upgrade in app.
On Sat, 05 Jul 2008, Russ Allbery wrote: Please check the following patch, which attempts to clarify how dpkg diversions should be handled. Once I started digging into this, the cases looked more complex than I had expected. I tried to add more language to explain the whole situation on the grounds that if I found it confusing, other people almost certainly also do. Looks reasonable, seconded. The postrm has to do the reverse: example - if [ remove = $1 ]; then + if [ remove = $1 -o abort-install = $1 -o disappear = $1 ]; then To be really complete we should also handle the abort-upgrade if the old version had no diversion... but that would make it too complicated for its purpose. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#143941: Mandate UTF-8 for control files
On Sat, 05 Jul 2008, Russ Allbery wrote: This transition is already complete in the archive, so this change catches Policy up with current practice. The new paragraph would go into Policy 5.1 (Syntax of control files). Seconds? Seconded. -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ signature.asc Description: Digital signature
Bug#426877: Clarify what sensible behaviour is for init scripts
Note that /etc/init.d/skeleton, on which many init scripts in Debian are
based, handles this case correctly without using --oknodo.
Are you sure? These are the start and stop sections of skeleton
file in a Debian Etch:
-
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec
$DAEMON --test /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one. As a last resort, sleep for some time.
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5
--pidfile $PIDFILE --name $NAME
RETVAL=$?
[ $RETVAL = 2 ] return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently. A last resort is to
# sleep for some time.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5
--exec $DAEMON
[ $? = 2 ] return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return $RETVAL
}
-
This is not the LSB behaviour. Athe --oknodo is just present in the
second call to start-stop-daemon of the stop action (and no more),
and the text is very clear:
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
2008/7/6, Russ Allbery [EMAIL PROTECTED]:
\Iñaki Baz Castillo [EMAIL PROTECTED] writes:
Op, sorry, I meant that lighttpd DOESN'T use LSB specs but Debian
specs.
You say that it's not a sensible behaviour to fail when asked to start
a service that is already running but this is the default behaviour of
Debian init scripts (dince --oknodo is optional and of course not always
used).
Note that /etc/init.d/skeleton, on which many init scripts in Debian are
based, handles this case correctly without using --oknodo.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
Iñaki Baz Castillo
[EMAIL PROTECTED]
Bug#426877: Clarify what sensible behaviour is for init scripts
On Sun, 06 Jul 2008, Iñaki Baz Castillo wrote: Note that /etc/init.d/skeleton, on which many init scripts in Debian are based, handles this case correctly without using --oknodo. Are you sure? These are the start and stop sections of skeleton file in a Debian Etch: No those are functions... the main code runs without set -e and thus doesn't fail on the error and the return value of the function is checked: do_start case $? in 0|1) [ $VERBOSE != no ] log_end_msg 0 ;; 2) [ $VERBOSE != no ] log_end_msg 1 ;; esac If do_start returns 0 or 1, the whole script returns 0 (hence success). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
Le samedi 05 juillet 2008 à 02:42 -0400, Daniel Dickinson a écrit : Gnome, KDE, and XFCE are the the top three desktops used in debian and cover most users of desktops in debian. They all use xdg .desktop-based menus as their main menu. The last time this discussion was raised up, the clear consensus was that, at least for the GNOME menu, the primary goals of the xdg-based menu system and those of the Debian menu are fundamentally different. The GNOME menu is aimed towards usability, and the Debian menu is aimed towards completeness. Given the capabilities of the GNOME panel (for which adding submenus is neither easy nor efficient in terms of usability), the limitations of the XDG system (for which it is not possible to define “views” including or excluding some categories) and the restrictions of the Debian menu system (no i18n support, 32x32 XPM icons, strict hierarchy), these goals are simply not compatible. Therefore, I still feel that, despite it being a big mess, the current situation is the best: * the default menu contains only what is needed, and we are still hunting down entries that are useless to make them not show up by default; * users wanting the Debian menu and its gazillions of entries including window managers, terminal emulators and shell interpreters can enable it easily in the menu editor; * those really wanting only the Debian menu can replace gnome-applications.menu by debian-menu.menu. If you want this to change, you need to seriously think about evolutions to both XDG and Debian menu systems, to convince fd.o and the Debian menu maintainer to implement them, and to find a good way to present them in a nice way in the main menu and in a menu editor. None of these tasks are simple. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#426877: Clarify what sensible behaviour is for init scripts
2008/7/6 Raphael Hertzog [EMAIL PROTECTED]: No those are functions... the main code runs without set -e and thus doesn't fail on the error and the return value of the function is checked: do_start case $? in 0|1) [ $VERBOSE != no ] log_end_msg 0 ;; 2) [ $VERBOSE != no ] log_end_msg 1 ;; esac If do_start returns 0 or 1, the whole script returns 0 (hence success). Thanks for pointing that, you are right. Anyway I consider it a bit complex and the fact is that various Debian init scripts return 1 in the above case. Thanks for all. -- Iñaki Baz Castillo [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
Josselin Mouette wrote: Therefore, I still feel that, despite it being a big mess, the current situation is the best: * the default menu contains only what is needed, and we are still hunting down entries that are useless to make them not show up by default; * users wanting the Debian menu and its gazillions of entries including window managers, terminal emulators and shell interpreters can enable it easily in the menu editor; * those really wanting only the Debian menu can replace gnome-applications.menu by debian-menu.menu. If you want this to change, you need to seriously think about evolutions to both XDG and Debian menu systems, to convince fd.o and the Debian menu maintainer to implement them Actually, no, if you want this to change, you have only to do nothing. People (many of them MOTUs from Ubuntu in my experience) are filing lots of requestes for random packages to have .desktop files added to them, so they appear in the gnome menu. The criteria seems to be a program that $RANDOM_USER would like to have on the menu and files a bug about || that $RANDOM_UPSTREAM ships a desktop file for, for whatever reason. So, after sufficient time, the gnome menu will contain a random assortment of the menu items that also appear in the debian menu. Not a well-chosen and consistent assortment, but the kind of random assortment that you get when you ignore policy and go off on your own way. -- see shy jo signature.asc Description: Digital signature
Re: gnome, kde, xfce use non-policy main menu
Twas brillig at 13:08:40 06.07.2008 UTC-04 when [EMAIL PROTECTED] did gyre and gimble: JH So, after sufficient time, the gnome menu will contain a random JH assortment of the menu items that also appear in the debian menu. fd.o menus are designed to allow distro-specific policy. It's the matter of Debian KDE/Gnome packaging/menu policy to get the proper subset of the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE menu and Qt/KDE - in Gnome one). -- pgppBkIxpMtNk.pgp Description: PGP signature
Re: gnome, kde, xfce use non-policy main menu
On Sun, Jul 06, 2008 at 01:08:40PM -0400, Joey Hess wrote: Josselin Mouette wrote: Therefore, I still feel that, despite it being a big mess, the current situation is the best: * the default menu contains only what is needed, and we are still hunting down entries that are useless to make them not show up by default; * users wanting the Debian menu and its gazillions of entries including window managers, terminal emulators and shell interpreters can enable it easily in the menu editor; * those really wanting only the Debian menu can replace gnome-applications.menu by debian-menu.menu. If you want this to change, you need to seriously think about evolutions to both XDG and Debian menu systems, to convince fd.o and the Debian menu maintainer to implement them Actually, no, if you want this to change, you have only to do nothing. People (many of them MOTUs from Ubuntu in my experience) are filing lots of requestes for random packages to have .desktop files added to them, so they appear in the gnome menu. The criteria seems to be a program that $RANDOM_USER would like to have on the menu and files a bug about || that $RANDOM_UPSTREAM ships a desktop file for, for whatever reason. I wouldn't be surprised if most of those had NoDisplay=true as one of the fields[0]. While there may be a drive to add .desktop files to packaging, there's a similar (sometimes overzealous, IME) drive to have them not displayed by default. [0] - https://wiki.ubuntu.com/UbuntuPackagingChanges?highlight=%28NoDisplay%29#head-5c07e3429829189474d24f6bcc1f2bee2f385e9a -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: gnome, kde, xfce use non-policy main menu
Mikhail Gusarov wrote: fd.o menus are designed to allow distro-specific policy. It's the matter of Debian KDE/Gnome packaging/menu policy to get the proper subset of the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE menu and Qt/KDE - in Gnome one). That might work for gnome and kde, which are both fairly well defined, to ignore menu items belonging to each other, but won't it be a game of whack-a-mole for the rest of the things with menu entries? (Just for example, I recently orphaned xgalaga, so its new maintainers decided to do something about #432398, which I had been sitting on for some time as this issue was not resolved. Now I check my gnome machine and it has two galaga menu items in amoungst the standard gnome games.) -- see shy jo signature.asc Description: Digital signature
Re: gnome, kde, xfce use non-policy main menu
On 2008-07-06, Mikhail Gusarov [EMAIL PROTECTED] wrote: fd.o menus are designed to allow distro-specific policy. It's the matter of Debian KDE/Gnome packaging/menu policy to get the proper subset of the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE menu and Qt/KDE - in Gnome one). I actually don't like this - just as I don't like the kde and gnome package sections. The users should have equal access to good programs. Most people (no matter what desktop they are using) thinks that - amarok is better than the gnome equivalent (rythmbox?) - gimp is better than the kde equivalent (released versions of krita) - kontact and evolution - fits different to different people At least, the KDE section seems to be a nice dumping ground for anything that links against kdelibs - and in some cases just Qt. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: user debian-pol...@packages.debian.org, setting package to debian-policy, tagging 241333 ...
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.30 user [EMAIL PROTECTED] Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]). package debian-policy Ignoring bugs not assigned to: debian-policy tags 241333 - patch Bug#241333: Mandate UTF-8 for changelog files Tags were: patch Tags removed: patch tags 241333 pending Bug#241333: Mandate UTF-8 for changelog files There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: user debian-pol...@packages.debian.org, setting package to debian-policy, tagging 143941 ...
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.30 user [EMAIL PROTECTED] Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]). package debian-policy Ignoring bugs not assigned to: debian-policy tags 143941 - patch Bug#143941: Mandate UTF-8 for control files Tags were: patch Bug#208011: Mandate UTF-8 for control files Tags removed: patch tags 143941 pending Bug#143941: Mandate UTF-8 for control files There were no tags set. Bug#208011: Mandate UTF-8 for control files Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241333: Mandate UTF-8 for changelog files
Kurt Roeckx [EMAIL PROTECTED] writes: Seconded. Thanks to you and Guillem for the review. Applied. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#143941: Mandate UTF-8 for control files
Raphael Hertzog [EMAIL PROTECTED] writes: On Sat, 05 Jul 2008, Russ Allbery wrote: This transition is already complete in the archive, so this change catches Policy up with current practice. The new paragraph would go into Policy 5.1 (Syntax of control files). Seconds? Seconded. Applied. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: user debian-pol...@packages.debian.org, setting package to debian-policy, tagging 416450 ...
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.30 user [EMAIL PROTECTED] Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]). package debian-policy Ignoring bugs not assigned to: debian-policy tags 416450 - patch Bug#416450: Add nocheck DEB_BUILD_OPTIONS option to suppress test suites Tags were: patch Tags removed: patch tags 416450 pending Bug#416450: Add nocheck DEB_BUILD_OPTIONS option to suppress test suites There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416450: [PROPOSAL] New option in DEB_BUILD_OPTIONS to avoid running test-suites
Raphael Hertzog [EMAIL PROTECTED] writes: On Sat, 05 Jul 2008, Russ Allbery wrote: Here's a slightly modified version of Guillem's patch that makes fewer assumptions about the structure of the debian/rules file in the example and doesn't refer to a non-mandatory target (install). Seconds? Seconded. Applied. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483418: Not limit dpkg-divert to install but valid also for upgrade in app.
Thanks for the review! Raphael Hertzog [EMAIL PROTECTED] writes: On Sat, 05 Jul 2008, Russ Allbery wrote: The postrm has to do the reverse: example - if [ remove = $1 ]; then + if [ remove = $1 -o abort-install = $1 -o disappear = $1 ]; then To be really complete we should also handle the abort-upgrade if the old version had no diversion... but that would make it too complicated for its purpose. Oh, hm, yes, the new postrm abort-upgrade is called in a useful place for it to fix this. But the abort-upgrade case would need to test the version number from which we're upgrading to determine whether to roll back the diversion. Since this is Policy (even an appendix), and since the failure case is what people most frequently get wrong, I think I'd like to try to capture the whole situation. Do you think that something like this is more confusing than it's worth? I think it is the fully correct handling. diff --git a/policy.sgml b/policy.sgml index 7d54e29..5975d37 100644 --- a/policy.sgml +++ b/policy.sgml @@ -10550,26 +10550,48 @@ install-info --quiet --remove /usr/share/info/foobar.info supposing that a prgnsmailwrapper/prgn package wishes to install a wrapper around file/usr/sbin/smail/file: example - if [ install = $1 ]; then - dpkg-divert --package smailwrapper --add --rename \ ---divert /usr/sbin/smail.real /usr/sbin/smail - fi - /example Testing tt$1/tt is necessary so that the script - doesn't try to add the diversion again when - prgnsmailwrapper/prgn is upgraded. The tt--package - smailwrapper/tt ensures that prgnsmailwrapper/prgn's - copy of file/usr/sbin/smail/file can bypass the diversion and - get installed as the true version. + dpkg-divert --package smailwrapper --add --rename \ + --divert /usr/sbin/smail.real /usr/sbin/smail + /example The tt--package smailwrapper/tt ensures that + prgnsmailwrapper/prgn's copy of file/usr/sbin/smail/file + can bypass the diversion and get installed as the true version. + It's safe to add the diversion unconditionally on upgrades since + it will be left unchanged if it already exists, but + prgndpkg-divert/prgn will display a message. To suppress that + message, make the command conditional on the version from which + the package is being upgraded: + example + if [ upgrade != $1 ] || dpkg --compare-versions $2 lt 1.0-2; then + dpkg-divert --package smailwrapper --add --rename \ + --divert /usr/sbin/smail.real /usr/sbin/smail + fi + /example where tt1.0-2/tt is the version at which the + diversion was first added to the package. Running the command + during abort-upgrade is pointless but harmless. /p p The postrm has to do the reverse: example - if [ remove = $1 ]; then + if [ remove = $1 -o abort-install = $1 -o disappear = $1 ]; then + dpkg-divert --package smailwrapper --remove --rename \ +--divert /usr/sbin/smail.real /usr/sbin/smail + fi + /example If the diversion was added at a particular version, the + postrm should also handle the failure case of upgrading from an + older version (unless the older version is so old that direct + upgrades are no longer supported): + example + if [ abort-upgrade = $1 ] dpkg --compare-versions $2 lt 1.0-2; then dpkg-divert --package smailwrapper --remove --rename \ --divert /usr/sbin/smail.real /usr/sbin/smail fi - /example + /example where tt1.02-2/tt is the version at which the + diversion was first added to the package. The postrm should not + remove the diversion on upgrades both because there's no reason to + remove the diversion only to immediately re-add it and since the + postrm of the old package is run after unpacking so the removal of + the diversion will fail. /p p -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470994: mail_spool default mode is 0660
Josip Rodin [EMAIL PROTECTED] writes: On Sat, Jul 05, 2008 at 04:26:25PM -0700, Russ Allbery wrote: Here is a proposed change to loosen this requirement. Please comment. One concern that I have with allowing either permission scheme is that if an MUA needs to recreate the spool file, how should it know what permissions to use? I guess we should grep the sources of a few MUAs (and MDAs) to see what they do. In the meantime, the new phrasing is still much better than the current text :) If someone has time to do that investigation, I think that would be very worthwhile. I guess that the point of that run-on sentence is the understanding that packages should not go out of their way to prevent such sysadmin changes, so it would make sense to add a full stop after the two options and write a proper new sentence about that. Yeah, I'm not at all sure what this language is really trying to say in practice. I took another shot at it below. Just a spelling fix - s/principal/the principle/ Thanks; Kerberos creates finger memory and makes it almost impossible for me to type principle. :) diff --git a/policy.sgml b/policy.sgml index 7d54e29..6969220 100644 --- a/policy.sgml +++ b/policy.sgml @@ -8062,12 +8062,27 @@ http://localhost/doc/varpackage/var/varfilename/var /p p - Mailboxes are generally mode 660 - ttvaruser/var:mail/tt unless the system - administrator has chosen otherwise. A MUA may remove a - mailbox (unless it has nonstandard permissions) in which - case the MTA or another MUA must recreate it if needed. - Mailboxes must be writable by group mail. + Mailboxes are generally either mode 600 and owned by + varuser/var or mode 660 and owned by + ttvaruser/var:mail/ttfootnote + There are two traditional permission schemes for mail spools: + mode 600 with all mail delivery done by processes running as + the destination user, or mode 660 and owned by group mail with + mail delivery done by a process running as a system user in + group mail. Historically, Debian required mode 660 mail + spools to enable the latter model, but that model has become + increasingly uncommon and the principle of least privilege + indicates that mail systems that use the first model should + use permissions of 600. If delivery to programs is permitted, + it's easier to keep the mail system secure if the delivery + agent runs as the destination user. Debian Policy therefore + permits either scheme. + /footnote. The local system administrator may choose a + different permission scheme; packages should not make + assumptions about the permission and ownership of mailboxes + unless required (such as when creating a new mailbox). A MUA + may remove a mailbox (unless it has nonstandard permissions) in + which case the MTA or another MUA must recreate it if needed. /p p -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
On 2008-07-06, Loïc Minier [EMAIL PROTECTED] wrote: of Debian KDE/Gnome packaging/menu policy to get the proper subset of the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE menu and Qt/KDE - in Gnome one). The users should have equal access to good programs. Are you commenting on OnlyShowIn? This feature is not meant to list No. the thing that makes moving Gnome/gtk application deeper in KDE menu... /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
On Sun, Jul 06, 2008, Sune Vuorela wrote: On 2008-07-06, Mikhail Gusarov [EMAIL PROTECTED] wrote: fd.o menus are designed to allow distro-specific policy. It's the matter of Debian KDE/Gnome packaging/menu policy to get the proper subset of the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE menu and Qt/KDE - in Gnome one). I actually don't like this - just as I don't like the kde and gnome package sections. The users should have equal access to good programs. Are you commenting on OnlyShowIn? This feature is not meant to list all GNOME-ish apps in GNOME and KDE-ish apps in KDE. It's meant to prevent some silly things to display across desktops. For instance gnome-about (About GNOME) shouldn't show in the KDE menus, nor should the configuration applets for window management, keyboard etc. which touch GNOME specific GConf settings, or nautilus-cd-burner... There are only 47 desktop files with OnlyShowIn on my system out of 218 desktop files installed, so it's not used too wildly I would say. (Some of these are probably bogus.) Most people (no matter what desktop they are using) thinks that - amarok is better than the gnome equivalent (rythmbox?) there isn't one GNOME player; I don't know whether amarok is OnlyShowIn KDE, but Rhythmbox should show up in KDE menus, just like Banshee and I hope the other players as well (Quodlibet, etc.). - gimp is better than the kde equivalent (released versions of krita) - kontact and evolution - fits different to different people These don't have an OnlyShowIn here and should show up in KDE menus. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483418: Not limit dpkg-divert to install but valid also for upgrade in app.
On Sun, 06 Jul 2008, Russ Allbery wrote: Since this is Policy (even an appendix), and since the failure case is what people most frequently get wrong, I think I'd like to try to capture the whole situation. Do you think that something like this is more confusing than it's worth? I think it is the fully correct handling. It looks fine, yes. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
initscripts: using /etc/init.d/package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all! Policy 3.8.0.1, 9.3.3, running initscripts say: The package maintainer scripts must use invoke-rc.d to invoke the /etc/init.d/* initscripts, instead of calling them directly. Then, but, it say: Most packages will simply need to change: /etc/init.d/package action in their postinst and prerm scripts to: if which invoke-rc.d /dev/null 21; then invoke-rc.d package action else /etc/init.d/package action fi ... which is fallback to using /etc/init.d directly if 'invoke-rc.d' is missing. But, how it can be? The package 'sysv-rc' that contains 'invoke-rc.d' has 'required' priority. I'm in a little confusion. - -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIcSr3chorMMFUmYwRAqwsAJ9t7GBeybLH0xHX163gbVv4chdIZgCgqRT4 xLcvI3XPTIbEeF82z8kbQaY= =tmjV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484656: gnome, kde, xfce use non-policy main menu
On Mon, 07 Jul 2008 00:13:30 +0700 Mikhail Gusarov [EMAIL PROTECTED] wrote: Twas brillig at 13:08:40 06.07.2008 UTC-04 when [EMAIL PROTECTED] did gyre and gimble: JH So, after sufficient time, the gnome menu will contain a random JH assortment of the menu items that also appear in the debian menu. fd.o menus are designed to allow distro-specific policy. It's the matter of Debian KDE/Gnome packaging/menu policy to get the proper subset of the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE menu and Qt/KDE - in Gnome one). But that's just the point; there is no policy. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org No more sea shells: Daniel's Webloghttp://cshore.wordpress.com signature.asc Description: PGP signature
Bug#484656: Fw: gnome, kde, xfce use non-policy main menu
Begin forwarded message: Date: Sun, 06 Jul 2008 14:28:15 +0200 From: Josselin Mouette [EMAIL PROTECTED] To: Daniel Dickinson [EMAIL PROTECTED] Cc: debian-policy@lists.debian.org, [EMAIL PROTECTED] Subject: Re: gnome, kde, xfce use non-policy main menu Le samedi 05 juillet 2008 à 02:42 -0400, Daniel Dickinson a écrit : Gnome, KDE, and XFCE are the the top three desktops used in debian and cover most users of desktops in debian. They all use xdg .desktop-based menus as their main menu. The last time this discussion was raised up, the clear consensus was that, at least for the GNOME menu, the primary goals of the xdg-based menu system and those of the Debian menu are fundamentally different. The GNOME menu is aimed towards usability, and the Debian menu is aimed towards completeness. Given the capabilities of the GNOME panel (for which adding submenus is neither easy nor efficient in terms of usability), the limitations of the XDG system (for which it is not possible to define “views” including or excluding some categories) and the restrictions of the Debian menu system (no i18n support, 32x32 XPM icons, strict hierarchy), these goals are simply not compatible. Therefore, I still feel that, despite it being a big mess, the current situation is the best: * the default menu contains only what is needed, and we are still hunting down entries that are useless to make them not show up by default; * users wanting the Debian menu and its gazillions of entries including window managers, terminal emulators and shell interpreters can enable it easily in the menu editor; * those really wanting only the Debian menu can replace gnome-applications.menu by debian-menu.menu. If you want this to change, you need to seriously think about evolutions to both XDG and Debian menu systems, to convince fd.o and the Debian menu maintainer to implement them, and to find a good way to present them in a nice way in the main menu and in a menu editor. None of these tasks are simple. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org No more sea shells: Daniel's Webloghttp://cshore.wordpress.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484656: Fw: gnome, kde, xfce use non-policy main menu
Begin forwarded message: Date: Sun, 6 Jul 2008 13:08:40 -0400 From: Joey Hess [EMAIL PROTECTED] To: debian-policy@lists.debian.org, [EMAIL PROTECTED] Subject: Re: gnome, kde, xfce use non-policy main menu Josselin Mouette wrote: Therefore, I still feel that, despite it being a big mess, the current situation is the best: * the default menu contains only what is needed, and we are still hunting down entries that are useless to make them not show up by default; * users wanting the Debian menu and its gazillions of entries including window managers, terminal emulators and shell interpreters can enable it easily in the menu editor; * those really wanting only the Debian menu can replace gnome-applications.menu by debian-menu.menu. If you want this to change, you need to seriously think about evolutions to both XDG and Debian menu systems, to convince fd.o and the Debian menu maintainer to implement them Actually, no, if you want this to change, you have only to do nothing. People (many of them MOTUs from Ubuntu in my experience) are filing lots of requestes for random packages to have .desktop files added to them, so they appear in the gnome menu. The criteria seems to be a program that $RANDOM_USER would like to have on the menu and files a bug about || that $RANDOM_UPSTREAM ships a desktop file for, for whatever reason. So, after sufficient time, the gnome menu will contain a random assortment of the menu items that also appear in the debian menu. Not a well-chosen and consistent assortment, but the kind of random assortment that you get when you ignore policy and go off on your own way. -- see shy jo -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org No more sea shells: Daniel's Webloghttp://cshore.wordpress.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484656: Fw: gnome, kde, xfce use non-policy main menu
Begin forwarded message: Date: Mon, 07 Jul 2008 00:13:30 +0700 From: Mikhail Gusarov [EMAIL PROTECTED] To: debian-policy@lists.debian.org Cc: [EMAIL PROTECTED] Subject: Re: gnome, kde, xfce use non-policy main menu Twas brillig at 13:08:40 06.07.2008 UTC-04 when [EMAIL PROTECTED] did gyre and gimble: JH So, after sufficient time, the gnome menu will contain a random JH assortment of the menu items that also appear in the debian menu. fd.o menus are designed to allow distro-specific policy. It's the matter of Debian KDE/Gnome packaging/menu policy to get the proper subset of the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE menu and Qt/KDE - in Gnome one). -- -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org No more sea shells: Daniel's Webloghttp://cshore.wordpress.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initscripts: using /etc/init.d/package
Eugene V. Lyubimkin [EMAIL PROTECTED] writes: The package maintainer scripts must use invoke-rc.d to invoke the /etc/init.d/* initscripts, instead of calling them directly. Then, but, it say: Most packages will simply need to change: /etc/init.d/package action in their postinst and prerm scripts to: if which invoke-rc.d /dev/null 21; then invoke-rc.d package action else /etc/init.d/package action fi ... which is fallback to using /etc/init.d directly if 'invoke-rc.d' is missing. But, how it can be? The package 'sysv-rc' that contains 'invoke-rc.d' has 'required' priority. Required priority doesn't mean that you can assume the package is always there. You still have to declare explicit dependencies or fall back if it's not unless the package is marked essential, which sysv-rc is not. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initscripts: using /etc/init.d/package
On Sun, Jul 06, 2008 at 04:38:26PM -0700, Russ Allbery wrote: Eugene V. Lyubimkin [EMAIL PROTECTED] writes: The package maintainer scripts must use invoke-rc.d to invoke the /etc/init.d/* initscripts, instead of calling them directly. Then, but, it say: Most packages will simply need to change: /etc/init.d/package action in their postinst and prerm scripts to: if which invoke-rc.d /dev/null 21; then invoke-rc.d package action else /etc/init.d/package action fi ... which is fallback to using /etc/init.d directly if 'invoke-rc.d' is missing. But, how it can be? The package 'sysv-rc' that contains 'invoke-rc.d' has 'required' priority. Required priority doesn't mean that you can assume the package is always there. You still have to declare explicit dependencies or fall back if it's not unless the package is marked essential, which sysv-rc is not. sysvinit is: Package: sysvinit Essential: yes Pre-Depends: [...] sysv-rc (= 2.86.ds1-1.2) | file-rc ( 0.7.0), [...] And both sysv-rc and file-rc provide invoke-rc.d. Since sysv-rc was split out of the sysvinit specifically to allow the alternative with file-rc, I think it's still intended that invoke-rc.d be regarded as an Essential interface? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initscripts: using /etc/init.d/package
Steve Langasek [EMAIL PROTECTED] writes: On Sun, Jul 06, 2008 at 04:38:26PM -0700, Russ Allbery wrote: sysvinit is: Package: sysvinit Essential: yes Pre-Depends: [...] sysv-rc (= 2.86.ds1-1.2) | file-rc ( 0.7.0), [...] And both sysv-rc and file-rc provide invoke-rc.d. Since sysv-rc was split out of the sysvinit specifically to allow the alternative with file-rc, I think it's still intended that invoke-rc.d be regarded as an Essential interface? Hm, yeah, probably so. Should we remove the fallback code in the Policy example and recommend people use invoke-rc.d unconditionally? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initscripts: using /etc/init.d/package
On Sun, Jul 06, 2008 at 05:36:10PM -0700, Russ Allbery wrote: Steve Langasek [EMAIL PROTECTED] writes: On Sun, Jul 06, 2008 at 04:38:26PM -0700, Russ Allbery wrote: sysvinit is: Package: sysvinit Essential: yes Pre-Depends: [...] sysv-rc (= 2.86.ds1-1.2) | file-rc ( 0.7.0), [...] And both sysv-rc and file-rc provide invoke-rc.d. Since sysv-rc was split out of the sysvinit specifically to allow the alternative with file-rc, I think it's still intended that invoke-rc.d be regarded as an Essential interface? Hm, yeah, probably so. Should we remove the fallback code in the Policy example and recommend people use invoke-rc.d unconditionally? I think that would be better. It makes me think, though, that we don't really have a place to centrally document what interfaces we consider essential and what ones we don't. Effectively, anything provided by a package that's a pre-dependency of an essential package can be treated as essential by this same logic, with sometimes unintended consequences if a maintainer later wants to drop an interface. So perhaps we should be explicitly blessing invoke-rc.d as virtually-essential, with the consent of the sysvinit maintainers, before changing the example? (For that matter, /usr/bin/awk is another virtually-essential interface in this category, and we've held forever that you don't have to depend on awk because base-files does this for us; but that's also not documented in policy, that I can see.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
