Bug#924401: #924401 base-files fails postinst when base-passwd is unpacked
On Mon, Feb 22, 2021 at 07:33:10AM +, Tim Woodall wrote: > As far as I can see, making base-passwd not essential, only required, > and then making passwd and base-files pre-depend on base-passwd the > system seems to bootstrap /etc/passed and /etc/group OK. > > That also seems to conform to the debian policy. The oddity is that > base-files and passwd only actually need to depend on base-passwd, not > pre-depend on it as they only use /etc/passwd and /etc/group in the > postinst scripts but the debian policy doesn't seem to consider this > case. base-passwd is independently essential to the functioning of the system as it currently stands, not just because base-files and passwd need it. As such I do not consider it correct to remove the Essential flag from base-passwd and won't be doing so. My view on this is that policy's definition of Essential should, for the time being, be refined to indicate that it only applies after the package has been configured at least once. Independently, I agree with other comments on this bug to the effect that it would be useful to extend dpkg such that initial copies of the essential files provided by base-passwd could be written without having to run base-passwd's maintainer scripts (something like the ability to provide an initial version of a configuration file without making it a full conffile), which would then allow simplifying the process, but I see no reason to block policy refinements on that; the policy manual is a living document and we can always update it again later once it's possible to simplify the bootstrapping process further. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Guidance on solving the username namespacing problem
[I haven't been following the rest of this discussion. Thanks for the CC - let me know if I'm egregiously missing anything.] On Sun, Jan 05, 2020 at 10:25:37AM -0800, Russ Allbery wrote: > Philipp Kern writes: > > It looks like the range must be contiguous, as it is compiled in[1]. > > What are the preexisting ones apart from netplan that you have in mind? > > It feels like systemd's boundaries are pretty arbitrary (0xEF00 to > > 0xFFEF) but at the same time we might want to reserve a range for it in > > policy - given that right now it is effectively squatting in that range? > > Yes. We should also coordinate this with Colin as the base-passwd > maintainer. Let me cc him explicitly. > > It's possible that we can just use the existing systemd range, provided > that we can find some workable approach for netplan. As Simon said, EF00-FFEF = 61184-65519 covers more than just netplan (https://salsa.debian.org/debian/base-passwd/blob/master/README), and several of the IDs allocated there in the vaguely recent past are hard to change (their rationales included "needs to be the same across multiple machines"), so I don't think we can use the existing systemd range - it needs to be adjusted for Debian at least to some extent. I'm not prepared to cede all of 64000-64999 to systemd; perhaps it would have been better if base-passwd had started at 6 instead, but we're here now. The rate of static allocations in 6-64999 is low enough that I'm not concerned in principle about carving off a slice of it for dynamic allocations by systemd-sysusers, and in any case I wasn't expecting to ever need to allocate more static IDs under 64000 (netplan was before my time). Perhaps we could start by reserving 61184-63433, given the netplan allocation? Yes, it's a bit arbitrary, but also not really all that stingy, and base-passwd's allocations are meant to be permanent even if the package has been removed (since we can never guarantee that it's been removed from users' systems). An alternative would be to reserve 61184-63999, with a Debian patch to exclude netplan's 63434. That doesn't seem likely to be difficult; it could go in the same place where systemd is already doing NSS checks. I'm generally in favour of the underscore prefix recommendation in some form, and would be happy to enforce that for new static allocations in base-passwd. -- Colin Watson [cjwat...@debian.org]
Bug#912059: debian-policy: please increase ToC depth (for Lintian's benefit)
Package: debian-policy
Version: 4.2.1.3
Severity: normal
Tags: patch
I recently noticed some outdated links generated by Lintian, which led
me to look into how they're generated. Lintian has a script
(private/refresh-manual-refs) to grab references from the tables of
contents of various Debian documents, which it then uses in some of its
tags. That currently has a hack for the main Policy document, dating
from last year:
'policy' => [
'/usr/share/doc/debian-policy/policy.html/index.html',
'https://www.debian.org/doc/debian-policy/',
# $index_re would match the Policy's TOC and work otherwise, but
# the TOC is generated only up to 3 levels deep as of 4.1.1.1, and
# we want refs to all levels.
qr{
<(h[2-5])>\s*
([A-Z]|[A-Z]?[\d\.]+?)
\.?\s+
([\w\s[:punct:]]+?)
]*?)\bhref="([^"]+)".+?
}x,
[['_ignored'], ['section'], ['title'], ['url']]
],
But this doesn't actually work at the moment: when I run this script it
loses all the policy entries from the output file. There is some
support for extracting additional subsection references from other
files, but it would take some effort to get this to work for policy,
because the order of fields in the regex would need to be a bit
different when parsing the primary index versus when parsing individual
ch-* files.
I think it would be much simpler to just increase the Policy ToC's
section depth. That would seem generally slightly more useful (there
isn't so much noise at the fourth level that it would make the ToC
substantially harder to read), and would relieve Lintian from having to
do this hack.
(See also #912055, a similar problem in doc-base.)
diff --git a/policy/index.rst b/policy/index.rst
index aa3fecd..b38e8c3 100644
--- a/policy/index.rst
+++ b/policy/index.rst
@@ -12,7 +12,7 @@ that each package must satisfy to be included in the
distribution.
This is Debian Policy version |policy_version|, released on |policy_date|.
.. toctree::
- :maxdepth: 3
+ :maxdepth: 4
:numbered:
ch-scope
@@ -31,7 +31,7 @@ This is Debian Policy version |policy_version|, released on
|policy_date|.
.. toctree::
:caption: Appendices
:name: appendix
- :maxdepth: 3
+ :maxdepth: 4
:numbered:
ap-pkg-scope
Thanks,
--
Colin Watson [cjwat...@debian.org]
Bug#850156: Please firmly deprecate vendor-specific series files [and 1 more messages]
On Wed, Apr 18, 2018 at 09:11:11PM -0700, Steve Langasek wrote: > There isn't even a guarantee that what gets synced to Ubuntu has ever > been unpacked - or *can* be unpacked - with dpkg-source. Indeed. Not only is there no guarantee, but it goes wrong in practice too. As an operator of merges.ubuntu.com, I run into this from time to time, because that service's daily operation involves unpacking all new versions of source packages and generating diffs from previous versions (yes, this predates attempts to get everything into consistent version control). When that service encounters a source package that simply can't be unpacked, it bombs out and an operator (i.e. me) has to deal with it. Fortunately this is not very common overall, but I've definitely seen a few cases where a source package could be unpacked on Debian but not on Ubuntu due to the use of an outdated vendor series file that was allegedly there specifically for Ubuntu's benefit. And that's leaving aside the related cases where a patch accidentally got omitted from Ubuntu because a maintainer forgot that they needed to update both series files (there's no #include mechanism - see #632305/#632313). It's not surprising to me that this happens, because the tooling for dealing with these files is IME not particularly good. You basically have to point quilt at a different series file and manually refresh a separate stack, and you have to remember to do that whenever you make any substantial change to the rest of the patch stack. Of course developers sometimes forget to do that, especially if they weren't the ones who introduced the ubuntu.series file in the first place. And given that these generally represent poorly-factored patches in any case in the ways that Steve and others have pointed out, I don't think it's a good use of time to try to improve the tooling. I second Steve's opinion that, in the aggregate, this feature is actively harmful to downstreams (notwithstanding some individual cases where it may be locally helpful) and should be removed. -- Colin Watson [cjwat...@debian.org]
Bug#846970: debian-policy: Proposal for a Build-Indep-Architecture: control file field
On Tue, Aug 01, 2017 at 07:47:47PM +0300, Adrian Bunk wrote: > 1. Debian does not currently have non-amd64 binary-all autobuilders > > Stating that binary-all packages in the archive are always being > built on amd64 would actually document the current status quo, > assuming source-only uploads. > > AFAIR pixfrogger and pixbros that I converted from binary-all to > an explicit list of all 32bit architectures were the last two > binary-all packages in main that could not be built on amd64. > > These were pretty rare cases of requiring a 32bit-only package, > and such a rare hack is better than mandating that Debian must > add binary-all autobuilders for every architecture. This is an essentially artificial argument that depends on the current (IMO unnecessarily complicated) way in which Debian happens to implement autobuilding of Architecture: all binaries. If they were just builds that happened on the normal autobuilders with a slightly different configuration, which would be perfectly possible, then nobody would need to worry about the effort of adding them for every architecture; any autobuilder would be able to build Architecture: all packages if it needed to do so. To me, as one of the maintainers of Ubuntu's autobuilding infrastructure, this is a sufficiently obviously simpler approach that I'm quite puzzled as to why the Debian buildd maintainers chose to implement it the way they did; I did talk to Andreas Barth about it at the time that he was doing the work, but I had the feeling neither of us was quite understanding the other. I can see the argument for not documenting this field in policy until the autobuilding infrastructure is actually able to cope with it (depending on how heavily one weights the downstream arguments), but I do think that the capability would fall quite naturally out of a better-designed infrastructure. I don't agree that your "explicitly list all 32-bit architectures" hack is better than having the improved infrastructure, even though it was probably necessary at the time. > 2. We were not able to build all binaries in a release > > For aboot and palo we are shipping binaries in jessie that cannot be > rebuilt in jessie since the build architecture is not part of jessie. > > Cross-compilers are available on amd64, and this is how palo and > openhackware were fixed for stretch. This has certainly been possible in some cases, but I still think it's more simply done at the builder level. And for the "build architecture not part of release" case, is it really worth shipping boot loaders for architectures where we don't ship the rest of the architecture? The rare case of systems building images for older releases could be handled by just installing binaries from older releases. -- Colin Watson [cjwat...@debian.org]
Re: [policy] 02/02: Clean up upgrading-checklist, bump version number
On Fri, May 05, 2017 at 02:19:32PM +0200, Guillem Jover wrote: > diff --git a/upgrading-checklist.xml b/upgrading-checklist.xml > index ec17af8..83e7c75 100644 > --- a/upgrading-checklist.xml > +++ b/upgrading-checklist.xml > […] > @@ -1438,11 +1449,11 @@ > > > > - > -Version 3.8.4.0 > + > +Version 3.8.4 > > > - Release Jan 2010. > + Released Janunary, 2010. ^ > > Typo. ^ :) Your typo fix introduces a different typo. :-) -- Colin Watson [cjwat...@debian.org]
Re: Bug#845369: debian-policy: [5.6.8] Not fully updated for "any all"
On Wed, Nov 23, 2016 at 09:00:56AM +1300, Olly Betts wrote: > In policy 3.9.3.0 (at least according to upgrading-checklist.txt): > > 5.6.8 > The `Architecture' field in `*.dsc' files may now contain the > value `any all' for source packages building both > architecture-independent and architecture-dependent packages. > > The current 5.6.8 does describe `any all`, but unfortunately it also still > contains this paragraph which is no longer correct since this change: > > In the main `debian/control' file in the source package, this field > may contain the special value `all', the special architecture wildcard > `any', or a list of specific and wildcard architectures separated by > spaces. If `all' or `any' appears, that value must be the entire > contents of the field. Most packages will use either `all' or `any'. > > I'd suggest updating this to: > > In the main `debian/control' file in the source package, this field > may contain the special value `all', the special architecture wildcard > `any', the special combination `any all`, or a list of specific and > wildcard architectures separated by spaces. If `all', `any', or > `any all` appears, that value must be the entire contents of the > field. Most packages will use either `all', `any', or `any all`. I think this proposed change would be a mistake. Any individual binary package listed in debian/control must either be architecture-dependent or architecture-independent; it is meaningless for it to be both. Section 5.2 makes it clear that Architecture may only occur in the binary package paragraphs in debian/control, not in the general paragraph at the top, and so the values of Architecture in debian/control may only be those that are meaningful for a single binary package. Contrariwise, the value of Architecture in the .dsc is an aggregation constructed by dpkg-source of the Architecture fields for all binary packages built by that source package. It is therefore meaningful for it to express a combination of architecture-dependent and architecture-independent binary packages. I would recommend closing this bug with no further action. The current text appears correct to me. -- Colin Watson [cjwat...@debian.org]
Bug#841877: Don't recommend contacting base-passwd maintainer for dynamic UIDs
Control: tag -1 patch On Sun, Oct 23, 2016 at 08:00:23PM -0700, Sean Whitton wrote: > Policy section "Permissions and owners" probably shouldn't recommend > contacting the base-passwd maintainer when selecting a username for a > dynamically-allocated UID created by a postinst maintscript. It should > continue to recommend contacting the base-passwd maintainer when the > postinst script needs to create a static UID. I (obviously) agree. How about this patch? I'm seeking seconds for this proposal. diff --git a/policy.sgml b/policy.sgml index 9cd182b..ab4f736 100644 --- a/policy.sgml +++ b/policy.sgml @@ -9610,9 +9610,7 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq that a dynamically allocated id can be used. In this case you should choose an appropriate user or group name, discussing this on debian-devel and checking - with the adduser in the preinst or postinst script (again, the latter is to be -- Colin Watson [cjwat...@debian.org]
Fw: don't miss up that new stuff
Dear, I found something absolutely new and so interesting! Don't miss it up, you may find more info here <http://relief.rogerdigmon.com/lnmhugkd> Sent from my iPhone, Colin Watson 74648153
Re: Re: Bug#748936: apt doesnt understand architecture wildcards
On Wed, Jan 20, 2016 at 03:17:18PM +0100, Bill Allombert wrote: > On Wed, Jan 20, 2016 at 01:39:45PM +0000, Colin Watson wrote: > > I think this is somewhat unfortunate, but it is the reality right now. > > Perhaps a good thing for somebody to work on would be reimplementing > > dpkg-architecture in C so that it could be moved to the dpkg binary > > package? > > As I understand, dpkg-architecture query the C compiler which is not > always avalaible. While that's true, it's partly just because it's architecture-independent code. A compiled version could build that information into the object code without much trouble. -- Colin Watson [cjwat...@debian.org]
Re: Re: Bug#748936: apt doesnt understand architecture wildcards
On Wed, Jan 20, 2016 at 12:31:52PM +0100, Balint Reczey wrote: > On 06/04/2014 03:41 AM, Guillem Jover wrote: > > * Other programs could “easily” use dpkg-architecture to check for > >identity or a match. (This poses problems for programs that do not > > I think making apt call dpkg-architecture for matching would be a good > way of ensuring consistency with dpkg. Caching the results in a hash > table would make matching even faster than it is currently. dpkg-architecture is in dpkg-dev, so not reliably usable at run-time. dpkg doesn't currently provide a way to make this kind of query without development tools installed. It's also probably not trivial to move it because its current implementation relies on dpkg's Perl modules, which also aren't part of the core dpkg binary package. I think this is somewhat unfortunate, but it is the reality right now. Perhaps a good thing for somebody to work on would be reimplementing dpkg-architecture in C so that it could be moved to the dpkg binary package? -- Colin Watson [cjwat...@debian.org]
Re: Bug#798714: debian-policy: Please explicitly recommend punctuation between the year, month and day components of date based version numbers
On Sat, Sep 12, 2015 at 10:17:44AM +0200, Axel Beckert wrote: > Henrique de Moraes Holschuh wrote: > > 2. -policy documents best current *ADOPTED* practice. > > That's new to me. For me, Policy is how it _should_ or _must_ be, by > steering things in the right directions. Policy generally does this about things which are important for interoperability between packages. I don't think it's the place for this kind of cosmetic recommendation, in either direction. The text we have today steers a good course: it warns against a couple of practices that might inadvertently be adopted without realising the implications (date formats that don't sort properly as versions, and the interaction between hyphens as separators and the semantics of hyphens in versions defined elsewhere in policy), but it simply says "possibly with punctuation between the components" etc. without taking a particular aesthetic stance. I think that's right. -- Colin Watson [cjwat...@debian.org]
Bug#679751: Lintian now detect package pointing to /home
On Fri, Jul 31, 2015 at 11:34:20AM +0200, Bastien ROUCARIES wrote: After a chat under #debian-qa it appear that canonical path for non existant home dir is /nonexistant could be documented ? If we do (and I'm not expressing any opinion on that here), we should spell it correctly: /nonexistent. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150806172515.ga4...@riva.ucam.org
Bug#747320: Mandate type in /bin/sh
On Wed, May 07, 2014 at 02:32:39PM +0100, Ian Jackson wrote: I therefore propose that the following should be added to the list of additional features listed in policy 10.4: * The XSI extension `type' must be supported . It must exit zero iff the command is found. The output format is not specified and scripts must not rely on it; scripts should rely only on the exit code using a construct such as if type foo /dev/null 21; then ... As the author of the original shell incarnation of what's now /usr/bin/which, and having worked around the lack of a policy-authorised in-process idiom for this in a number of places, I would also like to see such an extension in policy. It's been a long-standing irritation to have to duplicate this code everywhere for the sake of strict conformance. We should, though, survey the set of shells in Debian (excluding posh, which should follow policy in this regard) to find out if any of them lack type and if not make sure that they're extended appropriately. mksh seems to have it. I haven't checked any others. We need to say something about options. POSIX simply says none. dash treats all of its arguments as names regardless of whether they begin with an option. bash has a number of options and the GNU-style -- end-of-options indicator. Policy therefore probably ought to say that the behaviour of type with any arguments beginning with - is not specified (so you can't use bashisms like type -P to force a PATH search). -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507140925.ga2...@riva.ucam.org
Bug#642914: debian-policy: 10.8 Log files : logrotate compression should result from good judgment
On Mon, Sep 26, 2011 at 07:26:12PM +0200, Jérôme Bouat wrote: Hello Raphael, you have been filing such bugs in Ubuntu and I closed at least one you filed against dpkg. Ubuntu isn't exactly the same than Debian. Otherwise it would be called Debian ;) In many areas there is no reason for Ubuntu to diverge from Debian. This is one of them. -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110927082458.ga19...@riva.dynamic.greenend.org.uk
Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables
an explicit real-world situation in mind, the case of an unset PATH seems contrived enough that I don't think policy needs to spell out its exact behaviour in detail. In the particular case of #639997, I would also note that dpkg is acting to ensure that this statement in policy 6.1 holds, which serves to avoid maintainer scripts needing to be peppered with fragile absolute paths all over the place: Before installation is started, the package management system checks to see if the programs ldconfig, start-stop-daemon, install-info, and update-rc.d can be found via the PATH environment variable. Thus, independent of this discussion, dpkg has specific authorisation from policy to perform the check in question. 6.1 goes on to say: Maintainer scripts should also not reset the PATH, though they might choose to modify it by prepending or appending package-specific directories. These considerations really apply to all shell scripts. This clearly supports the position that programs do not need to take special measures to set their own PATH. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110903232012.ga12...@riva.dynamic.greenend.org.uk
Bug#487201: MPL in common-licenses and convenience of packaging mozilla extensions
On Mon, Aug 29, 2011 at 11:36:45AM -0500, Jonathan Nieder wrote: Allowing debian/copyright to rely on files _other_ than the common licenses in base-files would be a larger and different change, so off-topic for this bug. Unless done carefully, I don't think it's a good idea. And FWIW, since I haven't seen it stated in this bug thread as yet, the reason I've always seen for that restriction is that allowing such external references makes it more difficult for ftpmaster to review licences of new packages, and it's in the project's interest to allow them to do that efficiently. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110829165151.ga11...@riva.dynamic.greenend.org.uk
Re: [Piuparts-devel] Unclear failure for asclock (left over files in /var)
On Sat, Nov 28, 2009 at 10:04:30PM +0100, Guillem Jover wrote: On Sat, 2009-11-28 at 10:22:40 +0100, Holger Levsen wrote: On Mittwoch, 25. November 2009, Helge Kreutzmann wrote: Package purging left files on system: /var/cache/man/pt not owned /var/cache/man/pt/cat1 not owned [...] Judging from this analyis, this looks like a false positive... I think it is too, but I'm not entirely sure, so I would appreciate a comment from someone more familar with man then I am, that's why I've added d-qa@ to cc: So far, piuparts has been ignoring left over files with the following patterns: /var/cache/man/(.*)/index.db, /var/cache/man/index.db, (obviously, there are more :) Looking at the failed piuparts logs, I see there are more with left over files in /var/cache/man/.*/cat? - should piuparts just ignore /var/cache/man? Comments welcome. Ignoring /var/cache/man/ seems the most reasonable course of action to me. The man-db package is the one handling those databases, it just seems logical to me that it should be the one in charge of removing it when purged. It makes sense for mandb to observe that a hierarchy of manual pages has gone away entirely (e.g. no more /usr/share/man/pt) and remove the corresponding database. Could somebody file a bug on man-db for this, or reassign/clone an existing bug? I wasn't sure if there was already a bug report for this so I haven't filed one myself. Ignoring /var/cache/man seems fairly harmless in the meantime. (man-db of course does remove /var/cache/man when it itself is purged, but we could perhaps do better.) -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537707: groff limitations on manual page characters removed
Package: debian-policy Version: 3.8.2.0 Severity: wishlist groff 1.20.1 is now in unstable, and removes the limitations on characters in manual page source that formerly needed to be documented in policy. Of course we ought to wait until this new version is in testing before changing the policy manual, but I thought I might as well get the process started early. diff --git a/policy.sgml b/policy.sgml index d02f6c1..59352a5 100644 --- a/policy.sgml +++ b/policy.sgml @@ -8847,15 +8847,6 @@ name [varsyshostname/var]: filezh_CN/file, and filezh_TW/file are all allowed. /footnote /p - - p - Due to limitations in current implementations, all characters - in the manual page source should be representable in the usual - legacy encoding for that language, even if the file is - actually encoded in UTF-8. Safe alternative ways to write many - characters outside that range may be found in - manref name=groff_char section=7. - /p /sect sect Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533287: debian-policy: please clarify 10.7.4
On Wed, Jun 17, 2009 at 03:54:10PM +0200, Felix Zielcke wrote: For example we grub/grub2 maintainers have the problem that some people still have /sbin/update-grub in their /etc/kernel-img.conf. grub-legacy has a wrapper to warn about this since etch, but we recently got a bug report in grub2 who had it still in place (#500631). After I asked in #debian-devel my solution to this problem was to just abort in the preinst with an error message. Then I noticed #470894 where Colin Watson wanted to edit /etc/default/grub inside of grub-installer. And there I told him that I'm unsure if policy allows this and told him my solution to our problem. Let's discount the question of /etc/default/grub; it's not at issue here, and the solution you're using now for it is not questionable AFAICS. In message #36 [0] and #46 [1], he told me that we should either keep it as an symlink or just edit automatically /etc/kernel-img.conf /etc/kernel-img.conf is edited by grub-installer automatically to add update-grub to it. My concern is essentially, without intending offence to anyone involved, that we look stupid doing it the way we were doing it. :-) I'll quote my mail to debian-boot: # I'm sorry to have to say this, but the kernel-img.conf /sbin/update-grub # migration has been a hopelessly confusing mess. Please don't use it as # an example of anything except how *not* to do things. # # Either /sbin/update-grub should have continued to be supported forever # as a symlink without warnings, or (preferably) something should have # taken care of detecting the situation and rewriting the configuration # file automatically. Robert even suggested a way to do this in #361929, # but it was never done for some reason that is mysterious to me. # Complaining about the situation and aborting is the worst of both # worlds; it often merely throws users into confusion, or at best leaves # them cursing about how Debian didn't just sort out its own mistakes # rather than making users take care of it by hand. # # I understand, of course, that there are all sorts of reasons why these # sorts of things happen at the time; but if you look at the change as a # whole then it was very clearly far from optimal. /etc/kernel-img.conf is a weird case. To start with, it's initially created by the installer (base-installer) and the update-grub line is added by another part of the installer (grub-installer). Obviously the installer can't own a configuration file permanently, so we say that the kernel owns it because it's the primary consumer (and indeed historically it was using it before the installer did anything with it). Its format is clearly documented in kernel-img.conf(5). Of course, though, the kernel is not a single package, but a succession of packages with different names and very similar maintainer scripts generated by kernel-package, so its upgrade path is not simple. Furthermore, the requirement that update-grub be called without an explicit path (or at least not as /sbin/update-grub) comes from the grub package and is due to changes there; if the grub package insists on a change to a configuration file, as it did, then I do feel that it should be its responsibility to put its own house in order. (Normally I would say that a package should fix up its own mistakes, but in this case the mistaken entry in the configuration file comes from grub-installer, which is part of the installer and so can't do anything to fix up its mistakes on upgrade.) I would not object to the kernel packaging making this change instead, but of course we are then reliant on people actually upgrading to newer kernels, which is in practice not something that happens quite so reliably as normal package upgrades. People hang back on the kernel for all kinds of reasons. But, nevertheless, perhaps a kernel packaging person (Manoj?) could speak up and say whether they'd be willing to have the kernel fix up old /etc/kernel-img.conf files that mention /sbin/update-grub. The worst possible solution, in my book, is for grub to abort in its preinst and force the user to make the change by hand. If we end up doing that then we have put policy, or perhaps a failure to agree on implementation, ahead of the user. From the user's point of view, Debian (collectively) made this mistake and Debian should fix it up rather than bothering them about it. The warning was faintly ridiculous in the same way, and I certainly heard friends of mine who were upgrading from older versions of Debian object that we should just have fixed the file rather than complaining at them about its contents. I'm not too surprised that the recommendation I made to have grub edit /etc/kernel-img.conf rather than abort if it's wrong is contentious, I suppose. I don't think the situation is so clear that it is manifestly wrong - I certainly felt it to be justifiable, and I think the situation is distinctly muddy - though I concede it may not be the best possible answer. But then I don't know
Bug#532120: Require support for temporary /var/run/ and /var/lock in all packages
On Sat, Jun 06, 2009 at 05:01:46PM +0200, Julian Andres Klode wrote: The wording of Policy 9.3.2's /var/run and /var/lock may be mounted as temporary filesystems[60], so the init.d scripts must handle this correctly. only applies to init.d scripts. But init.d scripts are not the only scripts using /var/run. Bug#452198 is not RC if you apply this rule only to init.d scripts, because it provides no init.d script. Therefore, I propose to change the requirement so that all packages must support /var/run/ and /var/lock/ on temporary filesystems, and not only those which provide an init script. This seems reasonable to me; I don't think we'd foreseen this being a problem for things other than init scripts. Do you have a proposed patch for this, or a suggestion on how it might be better written? I thought a bit about moving the text somewhere else - maybe a new subsection under 9.1 - but I think the requirement applies *principally* to init scripts. Perhaps it would be best to simply add a parenthesis saying that this also applies to the rest of the system? -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian-policy 3.8.2.0 released
On Tue, Jun 16, 2009 at 10:31:22PM +0200, Bill Allombert wrote: I just released 3.8.2.0. Thanks for this. Sorry, I think I'd taken an action to do this but then had a flurry of activity elsewhere and it slipped off my plate ... -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
debian-policy FTBFS due to missing texlive-latex-extra build-dep
I happened to notice recently that debian-policy 3.8.1.0 fails to build due to a missing build-dependency on texlive-latex-extra. Since it's Architecture: all, of course, it's easy to miss this in Debian, but I noticed it in Ubuntu and then verified it in a relatively clean Debian chroot: http://launchpadlibrarian.net/26062790/buildlog_ubuntu-karmic-i386.debian-policy_3.8.1.0_FAILEDTOBUILD.txt.gz I've committed a fix to our git repository, of course, but I sort of feel that we shouldn't leave this kind of thing lying around for too long in debian-policy of all places. :-) Russ and others, would anyone mind if I rolled 3.8.2.0 with what we have now? Or does somebody else want to, or is there a reason not to do so (e.g. too much Standards-Version churn)? Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian-policy FTBFS due to missing texlive-latex-extra build-dep
On Wed, Apr 29, 2009 at 05:25:28PM -0500, Manoj Srivastava wrote: On Wed, Apr 29 2009, Russ Allbery wrote: I don't mind a release with what we have now. The churn is unfortunate since there's nothing particularly exciting in the changes committed so far, but I hate to leave FTBFS bugs lingering for that reason. Why not 3.8.1.1? Or do we have normative changes in there already? There are some normative changes. Nothing earth-shattering, but shifting to mandating debconf for user prompting (#206684) does seem to merit a normative version bump, at least. There are other normative changes but they're fairly trivial. That said, debconf was already recommended, so if people feel it would be better as 3.8.1.1, we could do that. Or alternatively we could branch off 3.8.1.0 in git and release 3.8.1.1 with just the non-normative changes? I'd be happy to put the legwork into sorting that out. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525151: Clarify format of source package name
On Wed, Apr 22, 2009 at 03:45:23PM +0100, Enrico Zini wrote: Package: debian-policy Version: 3.8.1.0 Severity: wishlist Tags: patch Hello, Policy 5.6.7. `Package' defines The name of the binary package., but it does not seem that the format of source package names is restricted anythere. Sanity as well as, I'd say, common use, would say source has the same format as binary. Clarifying it would be as trivial as this: 5.6.7. `Package' - The name of the binary package. + The name of the source and binary package. I think that would be incorrect; that section is very specifically talking about the Package field in a debian/control or .dsc file, and the Package field in such a file does *not* name the source package; that's the job of the Source field. It seems to me that it would be simplest just to copy the text from 5.6.7 (Package) to 5.6.1 (Source). Technically this imposes a new requirement on source packages that's slightly stricter than that imposed by dpkg-source, which from my brief reading of the code would theoretically permit colons, commas, equals signs, and tildes too, but I see no reason why those would be desirable and have never heard of anyone trying to use them in source package names. I agree with you that sanity and common use say that the two classes of package names have the same format. diff --git a/policy.sgml b/policy.sgml index 0140043..144cbfb 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2588,6 +2588,14 @@ Package: libc6 package control file when the source package has the same name and version as the binary package. /p + + p + Package names must consist only of lower case letters + (tta-z/tt), digits (tt0-9/tt), plus (tt+/tt) + and minus (tt-/tt) signs, and periods (tt./tt). + They must be at least two characters long and must start + with an alphanumeric character. + /p /sect1 sect1 id=f-Maintainer I'm seeking seconds for this. -- Colin Watson [cjwat...@debian.org] signature.asc Description: Digital signature
Bug#206684: mandatory use of debconf for user prompting a release goal for squeeze
On Wed, Mar 18, 2009 at 10:29:35PM +0100, Bill Allombert wrote: Is there actually packages that does not use debconf ? The one I'm involved with is base-passwd; but it only doesn't use debconf because I've been putting off dealing with figuring out how to convert it over (since it ideally ought to go along with asking slightly more fine-grained questions about changes, and since most of the logic is in a C program). Seeing as I'm a debconf co-maintainer, this is really just me being slack rather than anything that should hold up policy, though! -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514326: debian-policy: fhs-2.3 doesn't specify that /var/run and /var/lock may be volatile ref rcS(5)
tags 514326 pending thanks On Mon, Feb 16, 2009 at 08:06:00PM +, Tim Small wrote: Colin Watson wrote: Tim was referring to the text of the FHS, though (see the subject line), which I don't think we ought to modify in debian-policy for this. Yes, sorry about that, I hadn't appreciated that the FHS is independent of Debian.. Your proposed change to policy looks good. Thanks. I've committed this for the next release of policy. I wonder if it's worth adding a note/example that the install, and mkdir -p options in this context e.g. install -o owner -g group -m mode -Z SELinux_context -d /var/run/subdir ... just because I've seen some roundabout / verbose ways of creating such directories in various init scripts. If this is overly directive (or patronising) it could be left out, of course To be honest I think this is a bit too much detail for this section, and not really necessary for policy to specify; we don't generally mandate that people must write concise code! Regards, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#473439: pick consistent terminology for category/component/area
On Fri, Feb 13, 2009 at 07:41:40PM -0800, Russ Allbery wrote: Colin Watson cjwat...@debian.org writes: I'd say: The Debian Social Contract simply refers to areas. ... to emphasise the fact (as it seems to me) that the SC is non-specific. I don't think we should feel tied to the SC's vague choice of words. I strongly suspect that (a) the authors were more interested in getting across the principle than in clear nomenclature, and (b) the specific term components in our archive maintenance software postdates the SC. Since this is technical policy, it seems reasonable to me that we would generally prefer more specific terms. Here's an updated patch that includes this change and some other rewordings and which changes distribution area to archive area, which I think is more accurate and less ambiguous (no confusion with the Debian GNU/Linux distribution, for example). How does this look? I think this is fine except that you missed a couple of bits: list compact=compact item emsection/em if the package is in the - emmain/em category, + emmain/em distribution area, - emmain/em category, + emmain/em archive area, /item item - emsegment/section/em if the package is in + emarea/section/em if the package is in the emcontrib/em or emnon-free/em distribution areas. - distribution areas. + archive areas. Seconded with those modifications. -- Colin Watson [cjwat...@debian.org] signature.asc Description: Digital signature
Bug#514326: debian-policy: fhs-2.3 doesn't specify that /var/run and /var/lock may be volatile ref rcS(5)
On Sun, Feb 15, 2009 at 05:49:58PM +, Ian Jackson wrote: Tim Small writes (Bug#514326: debian-policy: fhs-2.3 doesn't specify that /var/run and /var/lock may be volatile ref rcS(5)): It should not be assumed that the contents of this directory will persist after a system reboot. I second this suggestion. Does Tim's proposed phrasing make it clear enough that all subdirectory structure may vanish ? I also second this. Tim was referring to the text of the FHS, though (see the subject line), which I don't think we ought to modify in debian-policy for this. The code that tends to suffer from this problem is init scripts, and so I think it would be sensible to add a requirement in that section of the policy manual proper. Here's a suggested patch (note that this adds a new must; other policy editors, is that a problem? I'd be happy to downgrade to a should if people are uncomfortable with it): diff --git a/policy.sgml b/policy.sgml index 36f51aa..75b236b 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6065,6 +6065,18 @@ test -f varprogram-executed-later-in-script/var || exit 0 script must behave sensibly and not fail if the file/etc/default/file file is deleted. /p + + p + file/var/run/file and file/var/lock/file may be mounted + as temporary filesystemsfootnote + For example, using the ttRAMRUN/tt and ttRAMLOCK/tt + options in file/etc/default/rcS/file. + /footnote, so the fileinit.d/file scripts must handle this + correctly. This will typically amount to creating any required + subdirectories dynamically when the fileinit.d/file script + is run, rather than including them in the package and relying on + prgndpkg/prgn to create them. + /p /sect1 sect1 -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514326: debian-policy: fhs-2.3 doesn't specify that /var/run and /var/lock may be volatile ref rcS(5)
On Mon, Feb 16, 2009 at 02:32:20PM +, Colin Watson wrote: The code that tends to suffer from this problem is init scripts, and so I think it would be sensible to add a requirement in that section of the policy manual proper. Here's a suggested patch (note that this adds a new must; other policy editors, is that a problem? I'd be happy to downgrade to a should if people are uncomfortable with it): Oh, for the record, this patch is derived from text I wrote for the Ubuntu Policy Manual. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Wed, Feb 11, 2009 at 09:27:17PM +, Adam D. Barratt wrote: The Policy section detailing the Distribution field in .changes files specifies that the field may contain a space-separated list of distributions. Whilst this is technically accurate, the feature has been deprecated since the testing distribution became an official part of the archive and is, imho, obsolete; the use case of uploading the same package to unstable and the frozen-stable-to-be as a single upload no longer applies. I discussed this with a couple of members of the ftpteam on IRC earlier today, and they were both in favour of removing support for the feature from dak. One of them had a dig through the archives and discovered that there have been no multiple-distribution uploads since 2004; even then there was only the one upload in that year, with the grand total of three in 2003. For Debian's archive, I think this change is entirely reasonable. However, I'm not convinced that it is correct to remove this feature from the *syntax*. While Ubuntu's archive maintenance software doesn't support it right now, several people have requested it (https://bugs.launchpad.net/soyuz/+bug/235064). If you're maintaining packages for a system that releases every six months, it turns out to be rather more likely in practice to be able to say that the same packages will work for several different releases, and less painful to maintain this state. .changes is a good format for interacting with Debian-format archives other than just Debian's, and this seems worth preserving. How about this patch instead (incorporating your fold of frozen into testing): diff --git a/policy.sgml b/policy.sgml index 36f51aa..78f2346 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3096,10 +3096,6 @@ Package: libc6 than unstable, but still risky. It is not possible to upload packages directly to emtesting/em. - /item - - tagemfrozen/em/tag - item From time to time, the emtesting/em distribution enters a state of code-freeze in anticipation of release as a emstable/em @@ -3124,7 +3120,9 @@ Package: libc6 p You should list emall/em distributions that the - package should be installed into. + package should be installed into. Note, however, that + the Debian archive only supports listing a single + distribution. /p p -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#473439: pick consistent terminology for category/component/area
On Sun, Feb 01, 2009 at 10:23:38AM -0800, Russ Allbery wrote: Kurt Roeckx k...@roeckx.be writes: On Sun, Jan 25, 2009 at 03:37:37PM -0800, Russ Allbery wrote: diff --git a/policy.sgml b/policy.sgml index 24c9072..16919b2 100644 --- a/policy.sgml +++ b/policy.sgml @@ -293,7 +293,13 @@ emfree/em in our sense (see the Debian Free Software Guidelines, below), or may be imported/exported without restrictions. Thus, the archive is split into the distribution -areas or categories based on their licenses and other restrictions. +areas or componentsfootnote + The Debian archive software uses the term component internally + and in the Release file format to refer to the division of an + archive. The Debian Social Contract refers to distribution + areas. This document uses the same terminology as the Social + Contract. +/footnote based on their licenses and other restrictions. The SC has this in it: We have created contrib and non-free areas in our archive [...] The packages in these areas are [...] packages in these areas [...] There is no combination with distribution. True. I added that because I thought it made the construct clearer, but perhaps it doesn't. I suppose we could use archive area instead, which is closer to the wording of the SC. Does that sound like a better idea? Or I could keep distribution area and just change the wording of the footnote to be more accurate, say: The Debian Social Contract refers to areas. (just removing the distribution word there). I'm happy with either choice. I mostly just want to close this old bug. :) I'd say: The Debian Social Contract simply refers to areas. ... to emphasise the fact (as it seems to me) that the SC is non-specific. I don't think we should feel tied to the SC's vague choice of words. I strongly suspect that (a) the authors were more interested in getting across the principle than in clear nomenclature, and (b) the specific term components in our archive maintenance software postdates the SC. Since this is technical policy, it seems reasonable to me that we would generally prefer more specific terms. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514919: Removing support for uploads to multiple distributions
On Thu, Feb 12, 2009 at 03:21:28PM +0100, Raphael Hertzog wrote: On Thu, 12 Feb 2009, Colin Watson wrote: However, I'm not convinced that it is correct to remove this feature from the *syntax*. While Ubuntu's archive maintenance software doesn't support it right now, several people have requested it (https://bugs.launchpad.net/soyuz/+bug/235064). If you're maintaining packages for a system that releases every six months, it turns out to be rather more likely in practice to be able to say that the same packages will work for several different releases, and less painful to maintain this state. .changes is a good format for interacting with Debian-format archives other than just Debian's, and this seems worth preserving. Agreed. In the long term, I would like to move all the documentation about the syntax into dpkg itself and have the policy document how Debian uses dpkg rather than documenting dpkg itself. The mythical dpkg programmer's manual? :-) I was never all that convinced. I do think there's value in the policy manual being coherent in itself, rather than depending on another manual for all the syntax. (I realise you already need to learn make and what-have-you, but it's currently fairly complete in terms of the things you need to build Debian packages on top of standard Unix tools.) -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504880: Disambiguate installed for packages
Package: debian-policy Version: 3.8.0.1 Severity: wishlist The policy manual currently uses the word installed in a couple of different ways when referring to packages. Sometimes it's speaking quite loosely, and in this sense is talking about something roughly equivalent to 'dpkg --install'. However, in some other cases it's using a sense of the word which I believe derives from dpkg's internal state machine, and which corresponds to 'dpkg --unpack'. On quite a number of occasions I've helped to explain this to people who were confused as a result: for instance, unless you realise the second sense, the definition of Conflicts is quite difficult to read. I suggest that the second sense should be written as unpacked rather than installed. Although this breaks the correspondence with dpkg's internal state machine, it brings the policy manual into line with the verbs used on dpkg's command line, which I think correspond much more reliably to how people think of the operation or state in question. I've attached a patch, and am seeking seconds for this proposal. Please double-check it for correctness, particularly the change in the definition of Breaks; I have only verified that against an old mail from Ian proposing the design of this field (http://lists.debian.org/debian-devel/1997/10/msg00643.html), not against the current implementation. Thanks, -- Colin Watson [EMAIL PROTECTED] diff --git a/policy.sgml b/policy.sgml index 7de382d..44ff374 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1034,8 +1034,8 @@ /p p - Sometimes, a package requires another package to be installed - emand/em configured before it can be installed. In this + Sometimes, a package requires another package to be unpacked + emand/em configured before it can be unpacked. In this case, you must specify a ttPre-Depends/tt entry for the package. /p @@ -3456,7 +3456,7 @@ Package: libc6 p Broadly speaking the prgnpreinst/prgn is called before - (a particular version of) a package is installed, and the + (a particular version of) a package is unpacked, and the prgnpostinst/prgn afterwards; the prgnprerm/prgn before (a version of) a package is removed and the prgnpostrm/prgn afterwards. @@ -3835,7 +3835,7 @@ Package: libc6 behavior which, though deterministic, is hard for the system administrator to understand. It can easily lead to missing programs if, for example, a package - is installed which overwrites a file from another + is unpacked which overwrites a file from another package, and is then removed again.footnote Part of the problem is due to what is arguably a bug in prgndpkg/prgn. @@ -3971,7 +3971,7 @@ Package: libc6 If there was a conflicting package we go and do the removal actions (described below), starting with the removal of the conflicting package's files (any that - are also in the package being installed have already + are also in the package being unpacked have already been removed from the conflicting package's file list, and so do not get removed now). /item @@ -4413,7 +4413,7 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386], p When one binary package declares that it breaks another, prgndpkg/prgn will refuse to allow the package which - declares ttBreaks/tt be installed unless the broken + declares ttBreaks/tt be unpacked unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured. /p @@ -4454,13 +4454,13 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386], p When one binary package declares a conflict with another using a ttConflicts/tt field, prgndpkg/prgn will - refuse to allow them to be installed on the system at the + refuse to allow them to be unpacked on the system at the same time. /p p - If one package is to be installed, the other must be removed - first - if the package being installed is marked as + If one package is to be unpacked, the other must be removed + first - if the package being unpacked is marked as replacing (see ref id=replaces) the one on the system, or the one on the system is marked as deselected, or both packages are marked ttEssential/tt, then @@ -4655,7 +4655,7 @@ Provides: mail-transport-agent Conflicts: mail-transport-agent Replaces: mail-transport-agent /example - ensuring that only one MTA can be installed at any one + ensuring that only one MTA can be unpacked at any one time. /sect1 /sect @@ -4887,7 +4887,7 @@ Replaces: mail-transport-agent footnote p During install or upgrade, the preinst is called before - the new files are installed, so calling ldconfig is + the new files are unpacked, so calling ldconfig is pointless. The preinst of an existing package can also be called if an upgrade fails. However, this happens during
Bug#504880: Disambiguate installed for packages
On Fri, Nov 07, 2008 at 09:26:05PM +0100, Kurt Roeckx wrote: On Fri, Nov 07, 2008 at 07:13:18PM +, Colin Watson wrote: The policy manual currently uses the word installed in a couple of different ways when referring to packages. Sometimes it's also using present while it probably also means unpacked. For instance: some packages may not be able to rely on their dependencies being present when being installed or removed You also didn't change that installed it seems? I left some of the vague uses intact when I didn't think they mattered very much. The uses of installed that I left intact by and large refer to operations that correspond roughly to 'dpkg --install'. In the case above, I think it could reasonably be replaced with installed, but present seems OK to me too. There is also: The `Depends' field should also be used if the `postinst', `prerm' or `postrm' scripts require the package to be present in order to run. Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Same as above. I don't think this is too confusing in practice, but feel free to suggest a supplementary diff if you do. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498300: specify that architecture-specific dependencies must have a non-empty list of architectures
On Mon, Sep 22, 2008 at 11:46:41PM -0500, Gunnar Wolf wrote: Stefano Zacchiroli dijo [Fri, Sep 19, 2008 at 01:46:05PM +0200]: As per policy the empty architecture list has no defined semantics, I guess that the only possible behaviours out there are the following: 1) require at least one entry (as did by python-debian) 2) assume a default polarity, this in turn would lead to one of the possible two semantics: a) (polarity positive) hence empty arch list means no architecture, i.e. useless dependency b) (polarity negative) hence empty arch list means no excluded architecture, i.e. always present dependency We can start betting on this possibilities :-) Umh... And I think I'd rather go with the negative polarity. This means that [] is a no-op. Positive polarity just kills all the dependency information for that dependency... And I doubt it is ever desirable! I don't know. It seems to me that the most likely reason for this is a substitution gone wrong, for example a debian/control.in file that looks like either: Build-Depends: foo [EMAIL PROTECTED]@] or: Build-Depends: foo [EMAIL PROTECTED]@] While I agree the latter is quite plausible, I can also easily imagine the former: for example, you remove the last of the lines that looks like FOO_ARCHES += i386 from debian/rules and forget that it's now empty. I don't think tools can reasonably guess this, and I'd prefer it if they simply rejected it up-front rather than trying to guess at a useful meaning for something that's clearly a mistake. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498300: specify that architecture-specific dependencies must have a non-empty list of architectures
On Mon, Sep 08, 2008 at 10:27:51PM +0200, Stefano Zacchiroli wrote: Section 7.1 of the policy includes a description of architecture-specific dependencies, correctly adding the following constraint: It is not permitted for some names to be prepended with exclamation marks while others aren't. the reason being that the semantics of the architecture list is either exclusive (if all archs are negated with '!') or inclusive (if all archs are not negated). A direct consequence is that an empty list of architecture (e.g. 'foo []') is meaningless as it cannot be determined whether it was meant to be inclusive or exclusive. Still, the policy does not say explicitly that the list should be non-empty, and in fact there are cases of (buggy) packages specifying empty architecture lists in arch-specific dependencies. Can you please add non empty just before mentioning the architecture list? Patch implementing that is attached. Seconded in principle (modulo the tab damage in your patch), although I'm interested in the following points: * What packages violate this constraint right now? * What happens to packages that violate this constraint right now? -- Colin Watson [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
On Sun, Jul 13, 2008 at 11:38:56AM -0700, Russ Allbery wrote: It's unfortunate that SUS requires free registration; it makes it harder to link directly to specific sections of interest. I've had http://www.opengroup.org/onlinepubs/009695399/nfindex.html bookmarked for a long time, which doesn't seem to require registration of any kind. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#478850: posh: $ENV variable processed by non-interactive shells
On Sat, May 03, 2008 at 09:52:16PM -0500, Manoj Srivastava wrote: On Thu, 1 May 2008 14:47:54 +0100, Clint Adams [EMAIL PROTECTED] said: On Thu, May 01, 2008 at 02:33:04PM +0100, Stephane Chazelas wrote: I don't really care about the interactive side of things ($ENV, $PSx, job control), but I tend to consider that for the scripting side of things, the optional features should be implemented. For instance, if you don't have command -v, there's no other reliable way to find out whether a command exists or not. So you have to have something (either command -v or type). If policy wants to mandate either command -v or type, we could conceivably move toward dropping which from debianutils. Well, type does not have a uniform implementation right now. And very few as as scripting friendly as which (most require you to remove junk from the output). Command -v also has mi9xed success. That said, which(1) has similarly non-standard output on other platforms. But indeed the reason I originally wrote the which(1) that ended up in debianutils is exactly that I was fed up of unparseable output and wanted something coherent. It'd be a great shame to drop it and thereby no longer have something we can rely on at least in Debian. (Not to mention that reshuffling tools just for the sake of it is a pain.) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475731: debian-policy: substvar reference moved from dpkg-source(1) to deb-substvars(5)
On Sat, Apr 12, 2008 at 04:35:59PM +0100, Ian Beckwith wrote: Policy 4.10 refers to dpkg-source(1) for details of variable substitutions. With the version of dpkg-dev in unstable, that information has moved to its own man page, deb-substvars(5). Patch attached. diff -Naur debian-policy-3.7.3.0.old/policy.sgml debian-policy-3.7.3.0/policy.sgml --- debian-policy-3.7.3.0.old/policy.sgml 2007-12-03 06:53:35.0 + +++ debian-policy-3.7.3.0/policy.sgml 2008-04-12 16:28:36.0 +0100 @@ -2012,7 +2012,7 @@ /p p - See manref name=dpkg-source section=1 for full + See manref name=deb-substvars section=5 for full details about source variable substitutions, including the format of filedebian/substvars/file./p /sect Seconded. -- Colin Watson [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#473761: [PROPOSAL] debconf specification should allow underscores in template names
Package: debian-policy Version: 3.7.3.0 Severity: wishlist The debconf specification says that (/-separated) template name components are limited to alphanumerics, '+', '-', and '.'. However, d-i and I suspect many other packages also use '_' extensively. As a debconf and cdebconf co-maintainer I can say that there's no harm in doing so, and that this should be allowed. Patch against current policy.git attached. I'm seeking seconds for this proposal. Thanks, -- Colin Watson [EMAIL PROTECTED] diff --git a/debconf_spec/debconf_specification.xml b/debconf_spec/debconf_specification.xml index 1690f76..ef8da7d 100644 --- a/debconf_spec/debconf_specification.xml +++ b/debconf_spec/debconf_specification.xml @@ -139,8 +139,8 @@ So, what do we need to store in a variable template? Of course we need a name to identify the template. Template names are made up of components separated by the character `/' (slash). - Each component is limited to alphanumerics and `+' `-' `.' - (plus, minus, full stop). + Each component is limited to alphanumerics and `+' `-' `.' `_' + (plus, minus, full stop, underscore). /para para A type is also needed so data can be verified. Here is a table signature.asc Description: Digital signature
Bug#71621: Policy on update-alternatives still needed
reopen 71621 thanks I recently ran into this yet again, with a set of packages (scim et al) calling update-alternatives --remove in 'prerm upgrade', and thereby breaking user configuration on every upgrade. I do not think that the issue has got significantly better in the 7.5 years since I originally reported this bug. Manoj closed this bug in 2002 with the comment Clarifying manual pages is not a policy issue. As I said in response to that at the time: I think #71621 is an interoperability and consistency issue, and thus suitable for policy. For instance, packages that remove and reinstall alternatives on upgrade (at least used to) break local configuration in the form of manually set alternatives, and I believe using update-alternatives in this way could cause alternatives to be sensitive to upgrade ordering when multiple packages providing the same alternative are upgraded in the same run. This feels like exactly the kind of thing that policy ought to mention. Policy documents other matters that consist of instructions on how to use system tools in ways that produce interoperable packages. For example, 8.1.1 ldconfig, 8.6.2 How to use dpkg-shlibdeps and the shlibs files, 9.2.2 UID and GID classes (adduser --system), and 9.3.3 Interfacing with the initscript system (update-rc.d). I do not see how update-alternatives is materially different from these. I'm not asking for policy to duplicate the manual pages. The manual pages tell you how to use the tools to perform specific actions, as they should. I'm asking for something at a higher level: policy should recommend standards for the actions that should be performed using these tools in order to produce packages that form a well-integrated, coherent system. This should not be news: policy already does this in other cases, so I simply want update-alternatives to be added to the family. The reason I care is that this is clearly a matter of great confusion. I don't think it's a matter of strong technical disagreement as such, otherwise I realise that the policy list probably wouldn't be the right place to bring it up; I think it's simply a matter where there is little guidance for developers and so it's easy for people to create subtle bugs, much as they probably would do if e.g. there were no guidance on the proper use of update-rc.d. Based on the analysis I did back in 2000, which I think is still largely sound, I think that policy should recommend that 'update-alternatives --remove' must not be called in any of prerm upgrade, prerm failed-upgrade, postrm upgrade, postrm failed-upgrade, postrm abort-install, or postrm abort-upgrade, because these cases cause an alternative to be removed that may shortly afterwards be reinstalled, which can make update-alternatives erroneously switch the alternative from manual to auto mode. Typically, a package should call 'update-alternatives --remove' in either prerm remove or postrm remove. However, in my original analysis I was unsure about the prerm deconfigure and postrm disappear cases; I would appreciate other contributions here. To go along with this, the result would be more readable and useful if the correct process for installing an alternative were also documented, although this is not something that people get wrong nearly so often. Please reconsider this bug. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
reread the previous paragraph while thinking of Makefile.in instead
of normal build results. It is common practice to do exactly that:
ship and use pre-built versions, or even ship them in the diff.gz (which
then gets huge). Makefile.am is only present as source-file, but it
isn't used at all during the build. Any changes the user makes will not
be noticed by the build system.
But this simply isn't true across the board! Makefile.am changes are
only ignored if you use AM_MAINTAINER_MODE. One reason people do that is
that it produces more predictable build-dependencies that aren't
affected by timestamp skew. This was more of an issue before bug #105750
was fixed. Nowadays, while I think the jury is still out in some places
regarding AM_MAINTAINER_MODE, the case for it is much less compelling
than it used to be, and the Automake manual explicitly recommends
against it. If you don't use AM_MAINTAINER_MODE, then Makefile.am
changes are automatically noticed and taken into account. A
demonstration:
$ apt-get source man-db
[...]
dpkg-source: extracting man-db in man-db-2.5.1
dpkg-source: unpacking man-db_2.5.1.orig.tar.gz
dpkg-source: applying ./man-db_2.5.1-2.diff.gz
$ cd man-db-2.5.1/
$ touch configure.ac
$ debian/rules build
./configure --prefix=/usr --libexecdir=\${libdir} \
[...]
touch configure-stamp
dh_testdir
/usr/bin/make CFLAGS=-O2 -g -Wall LDFLAGS=-g
make[1]: Entering directory `/home/cjwatson/man-db-2.5.1'
cd . /bin/bash /home/cjwatson/man-db-2.5.1/tools/missing --run
aclocal-1.10 -I m4 -I gnulib/m4
cd . /bin/bash /home/cjwatson/man-db-2.5.1/tools/missing --run
automake-1.10 --foreign
cd . /bin/bash /home/cjwatson/man-db-2.5.1/tools/missing --run autoconf
/bin/bash ./config.status --recheck
[...]
(The same goes for changing Makefile.am.)
Rather than incurring the pain of gratuitous full regeneration every
time, we just regenerate it when the user has changed something. Yes,
the user now gets to resolve any problems that might have been
pre-existing, but realistically either the Debian maintainer or the
upstream maintainer is probably going to run into those at some point
anyway.
I think we should recommend (but not require) that AM_MAINTAINER_MODE
not be used, and perhaps work to specify an optional debian/rules target
that regenerates the build system in an appropriate way. That seems to
provide the necessary benefits for users who need to change these files
without imposing an unacceptable burden on developers. I don't think
there's a good cause to go much further than that at this point.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008 at 08:24:43PM +0100, Loïc Minier wrote: Yes, I second Russ here and would like to add that it's very easy to trigger the timestamp skews if you simply create a patch for configure + configure.in/.ac as the files will be sorted as configure first and then configure.in/.ac so that applying the patch causes configure.in/.ac to be newer than configure... This isn't true if you just let the patch be applied by dpkg-source -x, since the timestamp-handling bug I mentioned earlier was fixed. It might be true if you use a less capable patching system. ;-) Also, automake/autoconf/aclocal might be triggerred while e.g. some m4 macros aren't installed on the buildd or the developer's system. Of course these are usually shipped with the upstream tarballs, but are often missing/incomplete. If that is the case then the end user is going to lose out anyway when trying to modify the package. I'm not arguing that such bugs shouldn't be fixed, merely that it's a mistake to turn them into showstoppers that could potentially block more urgent upload requirements. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
retitle 440420 [AMENDMENT 11/02/2008] Manual page encoding severity 440420 normal thanks On Mon, Jan 28, 2008 at 12:29:35PM +, Colin Watson wrote: --- orig/policy.sgml +++ mod/policy.sgml @@ -8521,6 +8521,37 @@ be present in the future. /footnote /p + + p + Manual pages in locale-specific subdirectories of + file/usr/share/man/file should use either UTF-8 or the usual + legacy encoding for that language (normally the one corresponding + to the shortest relevant locale name in + file/usr/share/i18n/SUPPORTED/file). For example, pages under + file/usr/share/man/fr/file should use either UTF-8 or + ISO-8859-1.footnoteprgnman/prgn will automatically detect + whether UTF-8 is in use. In future, all manual pages will be + required to use UTF-8./footnote + /p + + p + A country name (e.g. filede_DE/file) should not be included in + the subdirectory name unless it indicates a significant difference + in the language, as this excludes speakers of the language in + other countries.footnoteAt the time of writing, Chinese and + Portuguese are the main languages with such differences, so + filept_BR/file, filezh_CN/file, and filezh_TW/file are + all allowed./footnote + /p + + p + Due to limitations in current implementations, all characters + in the manual page source should be representable in the usual + legacy encoding for that language, even if the file is + actually encoded in UTF-8. Safe alternative ways to write many + characters outside that range may be found in + manref name=groff_char section=7. + /p /sect sect This has now acquired seconds from Guillem Jover, Christian Perrier, and Bill Allombert, so I'm raising it to the status of a formal amendment. -- Colin Watson [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#440420: [PROPOSAL] Manual page encoding
On Mon, Dec 31, 2007 at 02:37:48PM +, Colin Watson wrote: On Sun, Dec 30, 2007 at 10:28:12PM -0800, Russ Allbery wrote: Colin Watson [EMAIL PROTECTED] writes: I propose that policy should standardise that we move to using UTF-8 as the source encoding for all manual pages since it clearly makes sense to do so. [...] Right. Here's an update; I think I've captured most of the discussion in the thread so far. The following patch could in principle be applied now, given seconds. Wordsmithing welcome, as I'm aware that this is a rather dense recommendation; I'm also looking for seconds for this proposal. Christian Perrier seconded this here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440420#100 However, since later discussion indicated that we should drop the .UTF-8 business, I think we can also drop it from the policy proposal. (Manual pages still shouldn't lie about their encoding if they install files there, but since this will not be the recommended default there is no reason to bloat policy with it.) Here's another updated version. Christian, are you still OK with this? I'm also looking for at least one more second for this proposal. --- orig/policy.sgml +++ mod/policy.sgml @@ -8521,6 +8521,37 @@ be present in the future. /footnote /p + + p + Manual pages in locale-specific subdirectories of + file/usr/share/man/file should use either UTF-8 or the usual + legacy encoding for that language (normally the one corresponding + to the shortest relevant locale name in + file/usr/share/i18n/SUPPORTED/file). For example, pages under + file/usr/share/man/fr/file should use either UTF-8 or + ISO-8859-1.footnoteprgnman/prgn will automatically detect + whether UTF-8 is in use. In future, all manual pages will be + required to use UTF-8./footnote + /p + + p + A country name (e.g. filede_DE/file) should not be included in + the subdirectory name unless it indicates a significant difference + in the language, as this excludes speakers of the language in + other countries.footnoteAt the time of writing, Chinese and + Portuguese are the main languages with such differences, so + filept_BR/file, filezh_CN/file, and filezh_TW/file are + all allowed./footnote + /p + + p + Due to limitations in current implementations, all characters + in the manual page source should be representable in the usual + legacy encoding for that language, even if the file is + actually encoded in UTF-8. Safe alternative ways to write many + characters outside that range may be found in + manref name=groff_char section=7. + /p /sect sect Thus, an updated transition plan: 1. Initial status: packages should use only /usr/share/man/ll/ (although some packages have anticipated an approximation of the transition plan; we ignore these for the moment as there is little point in changing them only to change them back later), and must use the legacy encoding for pages installed there. 2. man-db 2.5.0-1 uploaded, including support for installing pages in /usr/share/man/ll.codeset/ (e.g. /usr/share/man/fr.UTF-8). The basename of this directory is not typically a well-formed locale, but it allows a clear specification of the hierarchy's encoding while applying to all countries using that language. [DONE] 3. man-db 2.5.1-1 uploaded, including 'man --recode'. We are now here; I uploaded man-db 2.5.1-1 this morning. 4. dh_installman updated to recode manual pages to UTF-8 automatically (and install them under /usr/share/man/ll.UTF-8/?), using 'man --recode UTF-8' to guess the original encoding. debhelper Depends: man-db (= 2.5.1-1) for this. Pages for which the DWIM fails can include an explicit coding: directive, which will be documented. Bug filed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462937 8. Distant future: deprecate /usr/share/man/ll/. This will only be for consistency, so there's no need to rush. This step is deleted. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#459403: libuuid1: missing depends on non-essential package passwd
On Mon, Jan 07, 2008 at 12:39:30PM +0100, Bill Allombert wrote: Since libuuid1 is essential, every system will end up with a libuuid user/group, so why not just add it to base-passwd instead of creating it dynamically ? In general I want to avoid almost all further creation of global static IDs. The last exception I made was when the installer needed a group with a static ID to exist so that it could hardcode its GID in /etc/fstab. Global static IDs are difficult to maintain, complicate partial upgrades, require user interaction (this should be overhauled, admittedly, but nevertheless), and have a very limited available space. I don't think but we don't want to make adduser Priority: required is a good enough reason to add global static IDs; and passwd doesn't need to be made Essential just because an Essential package depends on it (Essential isn't closed under dependency). Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
On Tue, Jan 01, 2008 at 11:37:30AM -0800, Russ Allbery wrote: Colin Watson [EMAIL PROTECTED] writes: I'm still open to whether new-world-order pages should go in /usr/share/man/LL.UTF-8 or just /usr/share/man/LL. Pros for LL.UTF-8: * Non-compliant implementations (I'm guessing xman, yelp, etc.) will display English manual pages rather than misencoded garbage. This might not be such a big deal for European languages, but for e.g. Japanese I suspect most people would prefer English to the spew you get by trying to interpret UTF-8 as EUC-JP. I'd rather fix the other implementations, frankly. All of Debian is moving towards UTF-8, as is all of the rest of the Linux world, and I'd rather not leave transitional measures around forever. Mm. I think I am increasingly leaning towards just using /usr/share/man/LL, seeing as man has to try decoding pages there as UTF-8 first anyway, but please comment if you care. I agree with this position. OK. I've changed man-db upstream to install its own translated manual pages in non-.UTF-8 directories again, and will incorporate this option into the transition plan when it comes time to send it to -devel-announce. Unfortunately 2.5.0 wasn't quite enough. Aside from a couple of stupid bugs (mostly fixed now), it turns out that we need an extra feature to allow debhelper to produce UTF-8 versions of manual pages without needing the source encoding to be explicitly specified, by guessing the encoding in the same way that man does: http://lists.debian.org/debian-i18n/2007/10/msg00063.html I committed this feature to my development trunk earlier today, and will be working on a 2.5.1 release over the next couple of weeks. After that I'll send Joey a patch for debhelper. It sounds like the same feature could be used by other man implementations that currently can't deal with UTF-8. Yes; doing so would also fix their misfeatures of attempting to locate manual pages on disk themselves rather than letting man do it. :-) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455602: debian-policy: Examples of dpkg frontends should mention apt now
On Sun, Dec 30, 2007 at 08:39:39PM -0800, Russ Allbery wrote: Josh Triplett [EMAIL PROTECTED] writes: Policy 7.2: (The other three dependency fields, `Recommends', `Suggests' and `Enhances', are only used by the various front-ends to `dpkg' such as `dselect'.) Since apt uses Recommends now, and can show Suggests, perhaps it would make a better example here. In any case, dselect now by no means represents the most popular dpkg frontend. Thanks for the report. I've applied a change to list apt and aptitude as well as dselect to my arch repository. Since the term apt really refers to the apt library and would therefore encompass aptitude, perhaps that should be apt-get and aptitude instead. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442070: Policy inconsistent with reality: base subsection no longer used
On Sun, Dec 30, 2007 at 08:29:27PM -0800, Russ Allbery wrote: Magnus Holmgren [EMAIL PROTECTED] writes: AFAIU, the base subsection was obsoleted with Etch (apparently, its removal was discussed already in 1997), and (almost) all packages moved to ordinary subsections, like other packages. However, it is still listed in section 2.4 and referred to in section 3.7. I think policy should contain or point to the real definition of the base system. That would be great. Could you, or someone else, get together with the debian-installer folks and whoever else would be an expert in what constitutes the base system and propose new wording for Policy? I don't have time to do the wordsmithing, but I can be your expert witness. debian-installer (specifically, debootstrap) now simply installs everything with Priority: required or Priority: important as the base system, and has done so for some time. See the changelog for debootstrap 0.3.1. Also, do you have a reference for the obsolescence of the base section? Even without the real definition of base (which I suspect is actually done by priority), if that section isn't used any more, we should remove it. (And remove it from lintian, etc.) I seem to remember that ftpmaster went through a while back and moved everything from base to other sections. A couple of packages seem to have sneaked back in, though; on my unstable system, I see lustre-source with Section: base and zd1211-firmware with Section: non-free/base (!). Unfortunately the list of sections in dak's configuration file appears to be global rather than per-suite, so it might require some work to make base an invalid section from here on without breaking old suites. Removing it from lintian would be good, though. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442070: Policy inconsistent with reality: base subsection no longer used
On Tue, Jan 01, 2008 at 11:49:02AM -0800, Russ Allbery wrote: Colin Watson [EMAIL PROTECTED] writes: I don't have time to do the wordsmithing, but I can be your expert witness. debian-installer (specifically, debootstrap) now simply installs everything with Priority: required or Priority: important as the base system, and has done so for some time. See the changelog for debootstrap 0.3.1. Okay, that implies to me that we've dropped the whole concept of a separate base section in favor of just using priorities. Right. Unfortunately the list of sections in dak's configuration file appears to be global rather than per-suite, so it might require some work to make base an invalid section from here on without breaking old suites. Removing it from lintian would be good, though. I'll queue that up for when the lintian Subversion repository comes back. (We really need to move to something distributed for lintian at some point.) Okay, I think this patch addresses the issues raised in this thread. Comments? Seconds? --- orig/policy.sgml +++ mod/policy.sgml @@ -640,14 +640,14 @@ p The Debian archive maintainers provide the authoritative list of sections. At present, they are: - emadmin/em, embase/em, emcomm/em, - emcontrib/em, emdevel/em, emdoc/em, + emadmin/em, emcomm/em, + emdevel/em, emdoc/em, emeditors/em, emelectronics/em, emembedded/em, emgames/em, emgnome/em, emgraphics/em, emhamradio/em, eminterpreters/em, emkde/em, emlibs/em, emlibdevel/em, emmail/em, emmath/em, emmisc/em, emnet/em, emnews/em, - emnon-free/em, emoldlibs/em, + emoldlibs/em, emotherosfs/em, emperl/em, empython/em, emscience/em, emshells/em, emsound/em, emtex/em, emtext/em, I second this part. @@ -1073,24 +1073,6 @@ /sect sect - headingBase system/heading - - p - The ttbase system/tt is a minimum subset of the Debian - GNU/Linux system that is installed before everything else - on a new system. Thus, only very few packages are allowed - to go into the ttbase/tt section to keep the required - disk usage very small. - /p - - p - Most of these packages will have the priority value - ttrequired/tt or at least ttimportant/tt, and many - of them will be tagged ttessential/tt (see below). - /p - /sect - - sect headingEssential packages/heading p Hmm. If this section is removed, then the definition of priorities should indicate that priorities required plus important make up what's installed as a base Debian system. I think this would be a bit unclear, though (you have to know the definition in order to work out where to find it), and so I think it would be better to keep this section but update its text. How about this? headingBase system/heading p The ttbase system/tt is a minimum subset of the Debian GNU/Linux system that is installed before everything else - on a new system. Thus, only very few packages are allowed - to go into the ttbase/tt section to keep the required - disk usage very small. + on a new system. Only very few packages are allowed to form + part of the base system, in order to keep the required disk + usage very small. /p p - Most of these packages will have the priority value - ttrequired/tt or at least ttimportant/tt, and many - of them will be tagged ttessential/tt (see below). + The base system consists of all those packages with priority + ttrequired/tt or ttimportant/tt. Many of them will + be tagged ttessential/tt (see below). /p /sect sect Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
On Sun, Dec 30, 2007 at 10:28:12PM -0800, Russ Allbery wrote: Colin Watson [EMAIL PROTECTED] writes: I propose that policy should standardise that we move to using UTF-8 as the source encoding for all manual pages since it clearly makes sense to do so. This will still need to be specified by each manual page (by means of the directory in which it is installed), and it does *not* affect what user locales are supported in any way. The internationalisation changes in man-db 2.5.0 will arrange for users to see pages in their native language when they did not before; I do not expect it to cause any users to fail to see pages in their native language when they previously did. Once man-db 2.5.0 is in place, the change in policy to recommend installing pages with UTF-8 encoding in a properly marked directory will have *no* effect on users, no matter what their locale. It is purely for improved maintenance of the system. Hi Colin, I assume that now that man-db 2.5.0 is in the archive, the original patch in this bug report is no longer current and we should now be saying something different. We're trying to increase the speed of Policy work, so hopefully this time we can get a change made in a timely fashion. :) Right. Here's an update; I think I've captured most of the discussion in the thread so far. The following patch could in principle be applied now, given seconds. Wordsmithing welcome, as I'm aware that this is a rather dense recommendation; I'm also looking for seconds for this proposal. --- orig/policy.sgml +++ mod/policy.sgml @@ -8521,6 +8521,43 @@ be present in the future. /footnote /p + + p + Manual pages installed under subdirectories of + file/usr/share/man/file with a codeset specification (e.g. + file/usr/share/man/fr.UTF-8/file or + file/usr/share/man/de_DE.ISO-8859-1/file) must be encoded + using the named character encoding. The subdirectory name does + not need to be a well-formed locale as in + file/usr/share/i18n/SUPPORTED/file; a language and + codeset, for example filede.UTF-8/file, is all that is + necessary for most languages.footnoteIn fact, specifying a + country is often harmful, as it excludes users of the language + in other countries; de_DE would apply only to speakers of + German in Germany, and not to those in Austria./footnote + /p + + p + For compatibility with both previous versions of Debian and + other systems, manual pages in other locale-specific + subdirectories of file/usr/share/man/file should use + either UTF-8 or the usual legacy encoding for that language + (usually the one corresponding to the shortest relevant locale + name in file/usr/share/i18n/SUPPORTED/file). For example, + pages under file/usr/share/man/fr/file should use either + UTF-8 or ISO-8859-1.footnoteprgnman/prgn will + automatically detect whether UTF-8 is in use. In future, all + manual pages will be required to use UTF-8./footnote + /p + + p + Due to limitations in current implementations, all characters + in the manual page source should be representable in the usual + legacy encoding for that language, even if the file is + actually encoded in UTF-8. Safe alternative ways to write many + characters outside that range may be found in + manref name=groff_char section=7. + /p /sect sect Not lying about your encoding is a safe must, I think, because this is pretty much indisputable and I know of no cases of this rule being broken in today's archive (though I haven't done a full scan). Once we're a little further into the transition, I would like to replace the second paragraph above with one that says that all manual pages should be encoded in UTF-8. I'm still open to whether new-world-order pages should go in /usr/share/man/LL.UTF-8 or just /usr/share/man/LL. Pros for LL.UTF-8: * Non-compliant implementations (I'm guessing xman, yelp, etc.) will display English manual pages rather than misencoded garbage. This might not be such a big deal for European languages, but for e.g. Japanese I suspect most people would prefer English to the spew you get by trying to interpret UTF-8 as EUC-JP. * Determining progress towards universal UTF-8 encoding can trivially be done by scanning Contents files rather than having to unpack the archive and run iconv over everything. * In the event that we later want to migrate to yet another universal encoding that can't be automatically distinguished from UTF-8, we already have the encoding name right there and migration will be straightforward. (I think this is an unlikely scenario.) And cons: * Many upstream developers using Debian systems will follow along without realising
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Wed, Dec 05, 2007 at 06:26:17PM +0100, Bill Allombert wrote: On Wed, Dec 05, 2007 at 05:08:49PM +, Colin Watson wrote: This has the unfortunate property of excluding Gnulib, which is a library of code explicitly designed by the GNU build system folks to live alongside the Autotools and be copied into packages to provide replacements for missing functions. Perhaps something like this would work? I expect that on a Sid system, there will be no missing functions to replace, so Gnulib will not actually embed code. Gnulib in fact provides a number of other useful utility functions as well as simply replacement functions (e.g. xmalloc, xasprintf, compile_csharp_using_pnet, execute_java_class) so this assumption may well not be correct. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400112: [PROPOSAL] forbid source/binary package name conflicts
On Wed, Oct 03, 2007 at 04:49:28PM +0100, Ian Jackson wrote: Manoj Srivastava writes (Bug#400112: [PROPOSAL] forbid source/binary package name conflicts): On Thu, 23 Nov 2006 22:45:18 +0100, Lucas Nussbaum [EMAIL PROTECTED] said: Some source packages generate binary packages using the same name as another source package. For example, see the 'qd' source package, and the 'qd' binary package generated by the kfolding source package (in contrib). Some tools don't like it at all (e.g sbuild), [...] Another example is the bug system. When you submit a bug you (used to) write: Package: source or binary package name Version: version of that source or binary package The BTS now provides `Source:' instead of `Package:' but it has not been widely publicised AFAIR, no-one uses it (not even automated rebuild testers and the like), ... and dak when closing bugs. That was one of the main points of adding it, actually; it was done during the upheaval for version tracking. (Conceptually, ordinary users file bugs on binary packages, while buildd maintainers, developers spotting a problem while reading source code, etc. file bugs on source packages. Neither obsoletes the other.) To make the existing interface to bugs.debian.org unambiguous the following rule is needed: If there are a source package and a binary package with the same name then (a) that binary package must be generated from the identically-named source and (b) the generated binary package version number must be the same as the generating source package version number I agree that the semantics of bugs.debian.org get tremendously difficult when these rules are violated. This caused me huge headaches when implementing version tracking, and I'm quite convinced that there are still internal bugs in this area, not to mention practically intractable UI bugs. As a (not very active these days) debbugs developer I support Ian's proposal. I am a little concerned that there may still be binary packages from different source packages on particular architectures at the moment (e.g. it used to be the case at least in Ubuntu that openoffice.org wasn't 64-bit-safe, so there was a separate openoffice.org-amd64 source package which generated the same binary packages built against 32-bit libraries). In most cases this is a ghastly hack and there are probably better ways to do it. However, it would be nice to know the extent of the problem before forbidding it. gcc-3.3 and gcc-3.4 still appear to have different source and binary package versions. More recent versions of gcc don't do this. Again, it would be nice to know the extent of the problem here. Why is this not considered a bug in the tools that needs to be fixed, rather than creating policy to work around bugs in the toolchain? I think that trying to fix everyone's brains not to get confused in this area is impractical. I concur. As Ian says, the BTS has had a disambiguating mechanism here (Source and Source-Version) for years, but nearly nobody uses it and frankly I don't blame them. The situation is rife with ambiguity and it would be much less confusing for everyone to forbid it. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
On Tue, Sep 04, 2007 at 02:04:32PM +0200, Jens Seidel wrote: On Tue, Sep 04, 2007 at 11:52:57AM +0100, Colin Watson wrote: Thanks. I hope that my comments above clarify some further confusion. I would still appreciate concrete information and examples on why you don't like the idea of manual pages being installed in UTF-8 (noting that as a package maintainer or a translator you wouldn't have to actually edit it in that encoding if you didn't want to, it doesn't have to be done urgently or on any kind of flag day, I have addressed the non-Latin concern above, and it will not have a negative effect on users of non-UTF-8 locales). Is it save to use UTF-8 characters if a very similar character exists in ASCII or can be expressed using groff macros? Think about the many dashes which exist in typography. Is it OK to use a UTF-8 hyphen sign instead of \(hy (same for en-dash, em-dash, ...) especially as the ordinary minus - is very similar in the output? Will man-db support all kind of white spaces (such as nbsp;) ...? You'll need to use the characters documented in groff_char(7) for this, at least for the time being. See below. Of course there exist transliterations of all these characters I'm currently talking about but it would probably make the live easier to restrict to ASCII if possible, right? I do appreciate that there are a few gotchas here. I think it is unduly cumbersome to express all non-ASCII alphanumeric characters using groff named characters, though. That option has been available for ages and translators have generally not taken advantage of it; I can entirely understand why not. Isn't there not also more than one way to express accented characters such as ä (as a single character and as 'a' followed by accent? groff 1.19 supports full Unicode-style composite glyphs, but the version we have doesn't (see the comment in my original bug report about groff versioning). Both our version and newer versions support named characters such as \[:a] or \(:a (variant spellings), again documented in groff_char(7). There's also the \N escape which can give you font-dependent numbered glyphs, which are Unicode codepoints if you happen to know that the utf8 device is in use. As above, though, these have been available and translators generally haven't used them; I can imagine that they're insanely cumbersome to use in practice for e.g. Japanese. So I'd really rather just support plain UTF-8 input for alphanumerics, which I think will actually get used. Do you think we will need explicit language in policy for this? For the time being, until we have a version of groff supporting direct UTF-8 input, the implementation will require that the page be convertible to the legacy encoding for that language using iconv (it'll use 'iconv -c' so that unknown characters are dropped rather than breaking the whole page, but all the same): so e.g. for German pages characters without a direct equivalent in ISO-8859-1 should be avoided. This seems like a reasonable thing to document after man-db 2.5.0, and would cover things like UTF-8 hyphen characters. I'm not sure how groff will handle such characters once it does have UTF-8 input support. I suspect it would convert U+2010 to its internal hy glyph and render that in whatever way is appropriate for the output device; that would really be ideal. However, I don't have enough information to make a decision based on that guess. In general, I think it's worthwhile for policy to make comments on encoding for purposes of interoperability and standardisation, but I'd be inclined to draw the line at filling it up with instructions on how to use groff correctly. Does this sound reasonable? Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
On Mon, Sep 03, 2007 at 08:30:39AM +0200, Jens Seidel wrote: On Sun, Sep 02, 2007 at 11:31:45PM +0100, Colin Watson wrote: On Sun, Sep 02, 2007 at 10:24:43PM +0200, Jens Seidel wrote: On Sat, Sep 01, 2007 at 01:02:33PM +0100, Colin Watson wrote: + is an ISO-639 language code, must be encoded with the usual + legacy (non-UTF-8) character set for that language, as shown + by: + example compact=compact +egrep -v '\.|@|UTF-8' /usr/share/i18n/SUPPORTED You are aware of the fact that some languages such as Vietnamese have a 8 bit encoding but do not match this regular expression (vi_VN.TCVN TCVN5712-1)? Hmm, yes. I'm not sure what to do about Vietnamese at the moment; I doubt it works properly right now. I'll check it out. I doubt it too... Regardless, to make it work with current groff (which reserves a part of the input character set for its own use and thereby conflicts with UTF-8 input), a legacy character set is needed; what I was trying to express is that this should be the most usual legacy encoding for that language. Vietnamese is an odd case. In the long term, I think being explicit (vi.UTF-8) is the right answer anyway. + the ttfr_BE.UTF-8/tt locale). It is therefore not yet + recommended to install pages encoded in UTF-8, but rather to Maybe it would be a good idea to explain what to do with non supported encodings these days. What to do with a Vietnamese page? Installing it now UTF-8 encoded into vi.UTF-8/ seems fine to me but you write not yet recommended! Well, that just plain won't work; man won't look there. There are some Yup, I'm aware of it. But once proper support to man-db is added it will work. There should be no need to upload a large amount of packages just to fix manual pages after the man-db transition if this can happen already now. (Or should currently not supported manual pages not be installed at all?) This is sort of what my caveat about the not yet recommended language was about. I agree with you that if it doesn't work with current man anyway then there is no harm in installing it in the future location. I'm not sure how to word this in policy though; do you have any suggestions? Maybe it would be better for me to just focus on getting man-db 2.5.0 done ASAP and not worry too much about policy in the meantime. :-) Isn't this the core idea of extenting the policy? To guide the developer what should/will be used once the transition happened? hex-a-hop installs already the Vietnamese and the Bulgarian manpages, both are currently not supported (at least in Etch and according to the changelog also in Sid -- and can be used as a test for you). (I will file a bug for Bulgarian on man-db soon.) That Bulgarian page is a particularly unfortunate example because it uses the ѝ character which is not in CP1251 (the encoding of the bg_BG locale), so right now we have no reliable path to render this page. I've added Bulgarian support anyway, it's just that this page will be a bit broken. I think you would be best advised to move this page to /usr/share/man/bg.UTF-8 given that it definitely won't work in /usr/share/man/bg. In the case of the Vietnamese page, please change the — character (U+2014) to \- as is standard in NAME sections; otherwise this works fine when recoded via TCVN5712-1 so I've added support for this too. Again, I think you would be best advised to install this in /usr/share/man/vi.UTF-8. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
On Mon, Sep 03, 2007 at 04:15:31PM +0200, Jens Seidel wrote: On Mon, Sep 03, 2007 at 01:11:04PM +0100, Colin Watson wrote: I'm not sure how to word this in policy though; do you have any suggestions? How about: It is therefore not yet recommended to install UTF-8 encoded pages if a classical encoding can be used instead, but rather to continue using the legacy encoding. That sounds reasonable, though I'd use the same term (either classical encoding or legacy encoding) in both places to avoid creating confusion about whether these might be two different things. /usr/share/man/bg. In the case of the Vietnamese page, please change the — character (U+2014) to \- as is standard in NAME sections; otherwise this works Oops, Clytie used a Unicode character and Lintian or po4a did not complained :-( I will file a bug against Lintian ... There's already a to-do comment in Lintian noting that it doesn't check non-English manual pages yet; this can be changed once man-db 2.5.0 is uploaded, but not really before. fine when recoded via TCVN5712-1 so I've added support for this too. Great, but I think TCVN5712-1 is not supported by po4a as output encoding. I meant having man do this automatically. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
On Mon, Sep 03, 2007 at 05:38:10PM +0200, Giacomo A. Catenazzi wrote: Colin Watson wrote: --- orig/policy.sgml +++ mod/policy.sgml @@ -8450,6 +8450,39 @@ be present in the future. /footnote /p + +p + Manual pages that are installed under + file/usr/share/man//filevarll/var, where varll/var + is an ISO-639 language code, must be encoded with the usual + legacy (non-UTF-8) character set for that language, as shown + by: + example compact=compact +egrep -v '\.|@|UTF-8' /usr/share/i18n/SUPPORTED + /example + footnote +This is necessary because many packages have historically +included manual pages encoded thus, and changing the +encoding of the whole hierarchy would involve a difficult +transitional period. + /footnote + Manual pages that are installed under + file/usr/share/man//filevarlocale/var, where + varlocale/var is a full locale name listed in + file/usr/share/i18n/SUPPORTED/file, must be encoded with + the character set implied by that locale. +/p I don't like the proposal ;-) It is not very POSIXly and to application specific. Of course it is application-specific; /usr/share/man is application-specific (i.e. specific to the man application). Methods of processing /usr/share/man that don't use /usr/bin/man are already broken in other ways. (man exports a number of specialised interfaces that can be used by frontends, and I'm happy to add more on request.) POSIX does not specify anything about the layout of /usr/share/man. The FHS makes an attempt, but it's horribly broken (speaking as one who has attempted to implement it), predates widespread deployment of UTF-8, and does not really help with the problem to hand anyway. 1- The POSIX way to specify locale is: language[_territory][.codeset] or [EMAIL PROTECTED] for some LC_ variables) Note that e.g. fr.UTF-8 matches this pattern, so I don't see your problem. The territory is intentionally omitted from the installation directory in my transition plan because it causes real problems. man will support full locale names under /usr/share/man, but in my transition plan I do not recommend using them because you don't typically want to make your French manual pages available only to users in France; they should be available to Belgians, French Canadians, Swiss French, and Luxembourgers as well. The standard exceptions well-known to internationalisation implementors are Chinese (zh_CN and zh_TW are different dialects and different scripts) and Portuguese (pt_PT and pt_BR are more or less different languages). It is confusing the legacy (non-UTF-8) character. Yes, it is, but it is current practice and I merely document it. If we were starting from scratch with the benefit of hindsight then obviously we wouldn't have done it this way. I think it's unambiguous for all languages where we actually have existing manual pages to worry about. Every locale has a charset. So the man page should be encoded according the right locale (in the manual PATH). My proposal (the diff, as opposed to the transition plan later in my original message) documents current practice, in which manual pages are installed in directories such as /usr/share/man/fr. fr is not a full locale name recognised by glibc, and does not have a defined character set in our system. Thus, we must define its character set by means of observing that historically pages installed there have been encoded in ISO-8859-1, and standardising that to prevent unsolvable encoding conflicts. In future, it absolutely makes sense to install the pages in /usr/share/man/fr.UTF-8 instead, which is where my transition plan takes us. But, for now, the only available alternatives are /usr/share/man/fr_FR.ISO-8859-1 and /usr/share/man/fr_FR.UTF-8, which (as above) have fundamental problems, and in any case are not well-supported at the moment (in man-db 2.4.*, /usr/share/man/fr_FR.UTF-8 will only be used if you are using that exact locale; in man-db 2.5.0, it will be used for users of the fr_FR (ISO-8859-1) locale as well and recoded on the fly, so that you don't have to install one manual page per possible encoding). 2- I've some problem with /usr/share/i18n/SUPPORTED Who generate this file? IIRC our glibc has more locales. glibc ships this file. $ dpkg -S /usr/share/i18n/SUPPORTED locales: /usr/share/i18n/SUPPORTED $ apt-cache show locales | grep Source: Source: glibc I don't find en, de. That's because glibc does not recognise those as valid locales. If you believe that a locale exists in our system but it is not in /usr/share/i18n/SUPPORTED, you are by definition mistaken. :-) 3- With the above point, I think that en (as example) has a charset (from glibc), so man page should be set with such charset. Your assumption is mistaken, I'm afraid. /usr/share/i18n/SUPPORTED is the canonical list of available locales in our
Re: New optional debian/rules targets for consistency of patch systems?
On Sun, Sep 02, 2007 at 04:27:27AM -0400, Daniel Schepler wrote: I'd like to get an opinion on a proposal for several new debian/rules targets I've been thinking of for a while now. The motivation here is that the different patch systems have differing targets required for applying or unapplying patches, which is highly annoying when trying to debug packages using them. For example, I think dpatch uses patch/unpatch, cdbs uses apply-patches/unapply-patches, and dbs needs make -f /usr/share/dbs/something.mk debian/stampdir/patch or something strange like that. So for consistency, I'd like to propose the optional targets: unpack Unpacks any embedded source tarballs into a build directory, without applying any patches. patch Applies all patches to the build directory, after unpacking sources if required. unpatch Reverts all patches which have been applied to the build directory. This would be fantastic and make working with the array of subtly different patch systems much less painful. Rather than simply saying optional for 'patch' and 'unpatch', I'd go a step further and propose something like source packages that apply patches after 'dpkg-source -x' should provide the following targets. Obviously finishing off the integration of patch systems into dpkg-dev would be better, but this would make life a lot less painful in the meantime. I imagine you will be called upon to provide justification for this particular choice of target names, at least from maintainers and users of patch systems that currently use different ones. I would suggest the rationale for these names that they are simple verbs in use by at least one patch system already, and they are the shortest of the target names currently in use. Perhaps start by filing bugs on patch system packages to provide these names as aliases and see if we can get some kind of vague consensus rather than bikeshedding? And while I'm at it: configure Prepares the build directory for compilation, for example by running autoconf scripts. How would this interact with source packages that perform multiple build passes? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
On Sun, Sep 02, 2007 at 10:24:43PM +0200, Jens Seidel wrote: On Sat, Sep 01, 2007 at 01:02:33PM +0100, Colin Watson wrote: --- orig/policy.sgml +++ mod/policy.sgml @@ -8450,6 +8450,39 @@ be present in the future. /footnote /p + + p + Manual pages that are installed under + file/usr/share/man//filevarll/var, where varll/var Please use file/usr/share/man/varll/var/file as ll is part of the filename. Thanks; consider it amended. + is an ISO-639 language code, must be encoded with the usual + legacy (non-UTF-8) character set for that language, as shown + by: + example compact=compact +egrep -v '\.|@|UTF-8' /usr/share/i18n/SUPPORTED You are aware of the fact that some languages such as Vietnamese have a 8 bit encoding but do not match this regular expression (vi_VN.TCVN TCVN5712-1)? Hmm, yes. I'm not sure what to do about Vietnamese at the moment; I doubt it works properly right now. I'll check it out. + At present, it is not generally possible to install a manual + page encoded in UTF-8 such that it will be used in all locales + for that language (for example, a page installed under + file/usr/share/man/fr_FR.UTF-8/file will not be used in + the ttfr_BE.UTF-8/tt locale). It is therefore not yet + recommended to install pages encoded in UTF-8, but rather to + continue using the legacy encoding.footnoteThis is expected + to change as of man-db 2.5.0./footnote Maybe it would be a good idea to explain what to do with non supported encodings these days. What to do with a Vietnamese page? Installing it now UTF-8 encoded into vi.UTF-8/ seems fine to me but you write not yet recommended! Well, that just plain won't work; man won't look there. There are some locales that are unfortunately left out in the cold at the moment. I'm working to improve the situation. (While man will look in /usr/share/man/vi_VI.UTF-8, that won't work properly either because groff doesn't accept UTF-8 input and man doesn't know how to recode that to an 8-bit encoding that can be passed through groff's ascii8 device and recoded back to UTF-8 on the other side. Basically, if man doesn't know about the legacy encoding for your language, you're currently screwed, and no amount of changes to policy will help you. Yes, this is far from ideal.) 5. Update dh_installman to recode manual pages to UTF-8 automatically and install them under /usr/share/man/ll.UTF-8/. Getting the This requires an option to specify the encoding of the manual page. Or assume UTF-8 by default for all languages not having a matching regular expression. I was thinking of having dh_installman recode to UTF-8, and yes, you would need to know the encoding somehow (maybe a table of legacy encodings as is currently in man-db would do the job). This is the least well-thought-out part of my transition plan, though, so ideas are good. Conflicts:/Breaks: in here might be difficult, plus I'm not sure Why not just ignoring this? If updating man-db is sufficient let's ignore dependencies. (If a HTML documentation file uses the new (fictitious) HTML version 9 there is no need to list all browsers supporting this in the dependencies.) Yeah, I'm open to just ignoring this. It's probably the pragmatic approach. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440420: [PROPOSAL] Manual page encoding
On Sat, Sep 01, 2007 at 02:49:20PM +0200, Kurt Roeckx wrote: On Sat, Sep 01, 2007 at 01:02:33PM +0100, Colin Watson wrote: + Manual pages that are installed under + file/usr/share/man//filevarll/var, where varll/var + is an ISO-639 language code, must be encoded with the usual + legacy (non-UTF-8) character set for that language [...] + Manual pages that are installed under + file/usr/share/man//filevarlocale/var, where + varlocale/var is a full locale name listed in + file/usr/share/i18n/SUPPORTED/file, must be encoded with + the character set implied by that locale. [...] 2. man-db 2.5.0-1 uploaded, including support for installing pages in /usr/share/man/ll.codeset/ (e.g. /usr/share/man/fr.UTF-8). The basename of this directory is not typically a well-formed locale, but it is appropriate because it allows a clear specification of the hierarchy's encoding while applying to all countries using that language. This part doesn't seem to be documented, or should the locale from the second case also apply to the not well-formed locale ll.codeset? Point 2. above is part of a transition plan that is not yet implemented, and so isn't part of the policy amendment I'm proposing now. (I only mentioned it in the same mail to anticipate questions about support for UTF-8 manual pages.) When it is implemented, I'll propose a further amendment that requires pages under /usr/share/man/ll.codeset to be encoded with codeset. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNUstep and FHS
On Sat, Jul 30, 2005 at 02:55:53PM -0700, Steve Langasek wrote: On Sat, Jul 30, 2005 at 12:26:04PM +0100, Colin Watson wrote: Brendan O'Dea has said things along these lines before, I know, but I'll repeat it: those wrappers are in most cases rather tightly bound to the precise interfaces exported by the architecture-dependent binary modules. The fact that they happen to be expressed in a form which is the same on all architectures doesn't make them truly architecture-independent, as architectures with different versions of the binary modules would generally need different versions of the wrappers too. Files are put in /usr/share because one might want to mount that directory on multiple machines. If putting something on a hypothetically NFS-mounted /usr/share means that you have to keep /usr/lib precisely in sync across all the machines that mount it for fear of breakage, you have to ask whether this is really a beneficial thing to do. But it's quite probable that there will be interdependencies between the contents of /usr/lib and /usr/share and yet other directories, requiring such strict synchronization. (Those would presumably be expressed by tightly-versioned dependencies among binary packages, where necessary. I could imagine an automatic scheme that spots when architecture-dependent binary packages are upgraded on one machine in a group and goes off to upgrade them on all the others.) It's not uncommon that sharing /usr requires fiddling with /etc across machines, even, but in particular I think that trying to NFS share /usr/share is just not worth the pain anyway. I tend to agree with you. In that case, I have to ask what the point is of getting het up about whether something's in /usr/share, if we don't think it's generally worth people's while actually sharing it. I can see why we should be strict about not allowing architecture-dependent files in /usr/share, since the few people who *do* actually share it would be seriously inconvenienced by that; but what important problem are we solving by being strict about architecture-dependent files in /usr/lib? My opinion is that being strict about whether files are in /usr/lib when they shouldn't be isn't solving any sufficiently important problem to consider it release-critical, and that packages should be allowed to deviate from this and use /usr/lib alone when it is extraordinarily difficult to distribute them properly across the hierarchy (as is apparently the case for GNUstep). The situation seems to me to be very similar to the question of whether architecture-independent data should go in a separate Architecture: all package or be part of some related Architecture: any package; in the past consensus has been that large chunks of data should generally be split out, but we've certainly never considered it release-critical if it isn't. At any rate, I'm not exactly bothered that there is arch-independent data in /usr/lib/perl; I'm just pointing out that it is a precedent. Right. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNUstep and FHS
On Sat, Jul 30, 2005 at 03:52:44AM -0700, Steve Langasek wrote:
On Sat, Jul 30, 2005 at 12:00:32PM +0200, Marc 'HE' Brockschmidt wrote:
Listing Perl, Python and Emacs here is totally wrong (and I don't know
enough about Java packaging to speak about it). Perl is the best
example: Architecture-dependend data is stored in /usr/lib/perl{/,5/},
arch-indep data in /usr/share/perl.
Not 100% true; /usr/lib/perl{/,5/} contain architecture-dependent binary
modules, *along with any architecture-independent wrappers that accompany
them*.
Brendan O'Dea has said things along these lines before, I know, but I'll
repeat it: those wrappers are in most cases rather tightly bound to the
precise interfaces exported by the architecture-dependent binary
modules. The fact that they happen to be expressed in a form which is
the same on all architectures doesn't make them truly
architecture-independent, as architectures with different versions of
the binary modules would generally need different versions of the
wrappers too.
Files are put in /usr/share because one might want to mount that
directory on multiple machines. If putting something on a hypothetically
NFS-mounted /usr/share means that you have to keep /usr/lib precisely in
sync across all the machines that mount it for fear of breakage, you
have to ask whether this is really a beneficial thing to do.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314808: Suggestion
On Wed, Jun 22, 2005 at 10:41:39AM +0200, Lukas Kolbe wrote: I don't really see a problem here. The FHS dictates: /src is site-specific. The Policy dictates: webapps-files in /usr/share/package/, which I strongly agree. Now, what prevents us writing helper-packages to maintain a subset of, say, /srv/webapps/? The underlined portion above. Consider: it's common practice to have /srv/$HOSTNAME for services hosted by the system. Let's say somebody's internal web applications hostname happens to be 'webapps' (and they decided not to bother with the FQDN in the directory). Now you've just trampled over their local configuration. If anything, /srv/www is even more likely to be already in use. Once something has been declared to be site-specific, you can't go back on that. Now, helper packages that maintained a *generic* location would be fine. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#303596: Emacs installation fails on vfat fs
On Sat, Apr 09, 2005 at 12:01:53AM -0700, Stephen Gildea wrote: I also point out that if a chown/chmod operation by root on an existent directory fails, there's nothing to be done about it, whether you notice it or not. My response would be inclined to be run fsck. Programs should report this kind of error and fail, because it may be the first sign of filesystem corruption. And regarding the example, it's just this, an example, and therefor probably not really a policy recomendation in itself. I agree. I notice that the example script fragment in 9.1.2 will not fail if the mkdir (the most important operation) fails. Thus I suspect that the script's failing if the chown or chmod fails is a bug in the example script. There's a good reason (specified above it) why the script doesn't fail if the mkdir fails, but given that the mkdir has succeeded I think it should be entitled to expect normal POSIX filesystem semantics after that. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: URI Enclosure in Angled Glyphs
On Tue, Dec 30, 2003 at 11:44:28PM -0500, Alexander Winston wrote: After speaking with Robert Jordens and several of my colleagues about it, I feel more comfortable encouraging the behavior that is referenced in RFC 2396, Appendix E. The suggestion is the enclosure of URIs---URLs included, of course---in the angle brackets and . The Unicode Consortium, or perhaps more specifically, The Unicode Standard, refers to these glyphs as LESS-THAN SIGN (U+003C) and GREATER-THAN SIGN (U+003E), respectively. This is a practice that makes good sense to me, but I am curious as to whether anyone else has any views on making this the suggested Debian method for referring to URIs. (For context, see bug #225585.) It definitely makes sense to me to recommend this for use in package descriptions, at least when the URI would be ambiguous due to being immediately followed by punctuation or similar. I'd prefer to avoid the URL: prefix that RFC 2396 mentions but notes is not common in practice; some people configure their terminal emulator to consider : as part of a word so that they can simply double-click to select a whole URI (at least if it's in a vaguely normal format), and the URL: prefix breaks that. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Init.d script, preventing start of one service
On Tue, Nov 11, 2003 at 04:27:03PM +0100, Sylvain LE GALL wrote: ps : i know ssh use a file to launch or not sshd, is it a good solution ? No, I don't think it is a good solution. I'm planning to split the ssh package into openssh-client and openssh-server at some point, which will get rid of that whole ugly edifice (and close several bugs as a result). I think having services in their own packages which you can uninstall if you don't want to run them is better than /etc/default cruft. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Tue, Nov 04, 2003 at 12:32:47AM +0100, Bill Allombert wrote: On Tue, Nov 04, 2003 at 12:10:19AM +0100, Josip Rodin wrote: What mandatory conversion to the new format in the long run? As I see it: currently there is version 0 and 1. Suppose one day version 2 is added. Requirement for version 2 will include requirement for version 1. If you want to implement version 2, you will have to implement version 1 even if it is not useful, say for a Arch: all source package. However, if you don't need version 2, you can stay to version 0. As a parallel, some of my packages are still using DH_COMPAT=1 debhelper interface, and no one is complaining. Although I keep seeing inexperienced developers converting packages to debhelper version 4 in NMUs. :-/ It's newer and shinier, so it must be better, right? (And I wonder how many versioned build-deps on debhelper go missing in the process, how many duplicate conffiles get created by incautious moves to DH_COMPAT = 3, and so on ... there's a reason we discourage cosmetic changes in NMUs.) If we're adding optional features, doing so in a way that doesn't confuse people into believing that all packages need to use them would definitely be a good thing, I think. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#218861: apt: apt-get should warn about removing required packages
On Sun, Nov 02, 2003 at 09:47:03PM -0500, Matt Zimmerman wrote: I'm not sure why libc6 is not essential, but since it is depended upon by essential packages, it is promoted to essential status anyway. Nothing else on that list would prevent things like dpkg from working. I'm copying debian-policy to see if there is some rationale for that definition that I am not aware of. Libraries can't be essential, because it would make it too hard to remove them when their sonames change. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
On Mon, Nov 03, 2003 at 11:57:51AM +0100, Bill Allombert wrote: On Mon, Nov 03, 2003 at 11:01:13AM +0100, Josip Rodin wrote: Well, regardless of whether we pick versions or listing available targets, why not do it with a new control file field in the source section? That seems logical, and avoids creating a new file. It's tangentially relevant that the .dsc and .changes files include a Format field that is a version number. Having a Rules-Format: 2 field in control seems okay to me. Some packages generate the control file at build time (e.g. from a control.in). We need to access the file before debian/rules is used, and debian/control might not exist yet. dpkg-source already requires debian/control to exist before it calls the rules file, so packages already have to make sure debian/control exists in their source package, even if they later change it. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Processed: your mail
On Mon, Oct 06, 2003 at 05:04:23PM +0200, Martin Godisch wrote: On Mon, Oct 06, 2003 at 16:17:12 +0200, Josip Rodin wrote: You're already the submitter of all of those, what's the point? To receive replies not CCing me. I'm sure I already said that this isn't an appropriate use of 'owner' (regardless of the fact that there isn't another good way just at the moment). -- Colin Watson [EMAIL PROTECTED]
Bug#212034: Debina Perl Policy manual uses dependency backards
On Sun, Sep 21, 2003 at 04:33:05PM -0400, Daniel B. wrote: Package: debian-policy Version: 3.5.6.1 The Debian Perl Policy manual (file:/usr/share/doc/debian-policy/perl-policy.html/ch-perl.html) uses the word dependency backwards. This error makes the documentation hard to understand. Debian's been using dependency this way round since roughly the dawn of time. I'm certain that trying to reverse it now would sow confusion among the entire developer population. Consider it a piece of jargon. -- Colin Watson [EMAIL PROTECTED]
Bug#212034: Debina Perl Policy manual uses dependency backards
On Sun, Sep 21, 2003 at 06:31:31PM -0400, Daniel B. wrote: Colin Watson wrote: I'm certain that trying to reverse it now would sow confusion among the entire developer population. 1. The current state is already confusing. I don't find it so in the least. 2. Fixing the problem doesn't require using dependency in the correct sense; it only requires _not_ using it backwards. For example, depended-on package (or library, etc., as the case may be) would be unambiguous and not much longer. That's a serious pain in the backside when you're discussing dependencies. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#209008: debian-policy: [PROPOSAL] common interface for parallel building in DEB_BUILD_OPTIONS
On Sun, Sep 07, 2003 at 01:33:36PM -0500, Manoj Srivastava wrote: On Sat, 6 Sep 2003 19:12:50 -0400, Joey Hess [EMAIL PROTECTED] said: Robert Jordens wrote: +ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS))) + PARALLEL_JOBS := $(shell echo $(DEB_BUILD_OPTIONS) | \ + sed -e 's/.*parallel=\([0-9]\+\).*/\1/') + ifeq ($(DEB_BUILD_OPTIONS),$(PARALLEL_JOBS)) + PARALLEL_JOBS := $(shell if [ -f /proc/cpuinfo ]; \ + then echo `cat /proc/cpuinfo | grep 'processor' | wc -l`; \ + else echo 1; fi) + endif +endif +MAKEFLAGS += $(NJOBS) That's a lot of boilerplate, almost enough to call for a program to parse DEB_BUILD_OPTIONS. I don't understand why we have an environment variable with a complex set of values in the first place. Surely something lile DEB_BUILD_OPTIONS_PARALLELL=n, DEB_BUILD_OPTIONS_NOPT, and DEB_BUILD_OPTIONS_NOSTRIP would not run us out of environment space, and it's far easier to work with. One of the reasons was to not have to have policy amended for every little variable that one came up with; the omnibus version allows the list of things to be added to at will. Admittedly, this makes for complex code; if the list gets too large I don't see why policy would have to be amended for every little variable any more than it currently does. We could easily just say that variables named DEB_BUILD_OPTIONS_* may affect the build process, and that the following are currently defined: etc. That'd be just the same as the current situation as far as amending policy goes. We're claiming a namespace, that's all. We do have the problem that policy recommends, and virtually everyone implements, the $(findstring) idiom, which means that we can never add a DEB_BUILD_OPTIONS flag whose name has an existing flag as a substring. While it may not actually be a problem with the current set of flags - although I can easily imagine wanting to add something that contained debug, an old flag - I've always felt that this situation is uncharacteristically technically suboptimal. Using separate environment variable names would fix that problem, not that I particularly relish the idea of trying to get it changed everywhere. If we didn't want to change the existing flags, we could still reserve DEB_BUILD_OPTIONS_* for extensions. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
On Mon, Sep 01, 2003 at 10:58:50AM +0200, Martin Godisch wrote: --- debian-policy-3.6.1.0.orig/policy.sgml2003-08-19 14:32:23.0 +0200 +++ debian-policy-3.6.1.0/policy.sgml 2003-09-01 10:52:12.0 +0200 @@ -5362,13 +5362,16 @@ tagttforce-reload/tt/tag itemcause the configuration to be reloaded if the service supports this, otherwise restart the - service./item + service,/item + + tagttstatus/tt/tag + itemprint the current status of the service./item /taglist I'd like to see a standard message format in section 9.4 (Console messages from init.d scripts). It's probably appropriate to let init scripts provide more detail if it's useful in particular cases, but something like: Checking status of printer spooler: running. Checking status of OpenBSD Secure Shell server: stopped. ... as the first line of the output would be kind of nice. -- Colin Watson [EMAIL PROTECTED]
Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting
On Fri, Aug 22, 2003 at 07:17:57PM +1000, Anthony Towns wrote: On Fri, Aug 22, 2003 at 07:46:56AM +0200, Christian Perrier wrote: This proposal is what I think to be the next step : make this a must This won't be happening for sarge. If you want it to happen, please focus your efforts on finding packages that don't do it, and supplying patches to add the features instead. In fairness, he did say that: Of course, this *has* to wait after sarge release. It wouldn't be realistic to include this in the Debian Policy version which will be used for sarge. I'd like to add one thing to the proposal: there needs to be an exemption somehow for packages with high priority, e.g. Essential packages and those in the dependency chain of debconf itself. Such packages must be allowed to use debconf only if available, and otherwise fall back to other means of prompting the user. -- Colin Watson [EMAIL PROTECTED]
Bug#80343: Some 2 year old proposals
On Thu, Aug 21, 2003 at 11:35:28AM -0500, Manoj Srivastava wrote: * #80343: [PROPOSAL] policy should say no files should be owned by nobody Package: debian-policy; Severity: wishlist; Reported by: KORN Andras [EMAIL PROTECTED]; 2 years and 239 days old. Hmm. Do people think this is required? Are there any files/directories owned by nobody? If so, why is that not already a bug? Should policy state, in effect, do not create bugs in your package? FWIW, /usr/share/doc/base-passwd/users-and-groups.html now exists and says that nobody should never own any files, along with I think most of the other advice suggested in this bug report. I'm not sure if you'd want to give that document the weight of policy, but perhaps it would be worth referring to it informationally for general documentation of the globally allocated users and groups on Debian systems. -- Colin Watson [EMAIL PROTECTED]
Bug#203650: Poor recommendation in dpkg-statoverride section
On Mon, Aug 04, 2003 at 10:37:53PM -0500, Adam Heath wrote: On Tue, 5 Aug 2003, Herbert Xu wrote: On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote: You're confusing pre-depends and essentialness. What about the case if adduser needs a new feature in useradd and thus uses a versioned dependency on passwd. This means that the new adduser can be unpacked before the new passwd is unpacked or configured since it's only a plain old dependency. As an unversioned pre-dependency is fulfilled as long as a package was previously configured, this will allow packages declaring pre-dependencies on adduser to run their preinsts even though the new passwd is not yet available, rendering adduser useless. No. If foo pre-depends on bar, dpkg guarantees that bar is in a configured state, before it even considers doing anything with foo. And foo can only be in a configured state, if all it's normal deps(conflicts/etc) are sane. Please, get your dependency resolution straight. This is not rocket science. Adam, the depisok() function in dpkg 1.10.10 says: * allowunconfigd should be non-zero during the `Pre-Depends' checking * before a package is unpacked, when it is sufficient for the package * to be unpacked provided that both the unpacked and previously-configured * versions are acceptable. The code in this function and in predeppackage() appears to agree. Furthermore, this behaviour is what is described in policy. Herbert seems to be quite correct. -- Colin Watson [EMAIL PROTECTED]
Bug#203650: Poor recommendation in dpkg-statoverride section
On Mon, Aug 04, 2003 at 11:05:54AM -0500, Adam Heath wrote: On Sat, 2 Aug 2003, Herbert Xu wrote: A single pre-dependency is not enough. You will need to convert all of adduser's dependencies into pre-dependencies, and probably most of the things it depends on as well. No. adduser can still use normal depends. Pre-depends just means the dep'd on package has to be configured. And depends are for this exactly. You're confusing pre-depends and essentialness. I thought the same at first, but according to policy, pre-depends also allows the depended-upon package to be merely unpacked or half-configured provided that it has been fully configured at some point in the past. Is this not correct? -- Colin Watson [EMAIL PROTECTED]
Bug#203650: Poor recommendation in dpkg-statoverride section
On Sun, Aug 03, 2003 at 10:23:10PM +0200, Jakob Bohm wrote: On Sat, Aug 02, 2003 at 09:59:13AM +1000, Herbert Xu wrote: A single pre-dependency is not enough. You will need to convert all of adduser's dependencies into pre-dependencies, and probably most of the things it depends on as well. You also need to ensure that adduser and anything that it depends on to function are always available at all times just like libc6. Note that only a few packages will need these dependencies, unlike libc6. Specifically, these packages will be needed by a subset of the packages that currently Depends: adduser . Of those packages, only two are non-optional: ssh and pidentd. To fix that, the sshd and ??? accounts would need to be added to base-passwd. The ssh package does not contain any files owned by the sshd user, even after configuration, although it does arrange for /usr/bin/ssh-agent to be setgid ssh. Policy-wise, there would be a rule that packages with priority standard or above cannot use the option to add needed users during installation, but must coordinate their needs with base-passwd. I disagree (as base-passwd maintainer, although only for some months) with this principle; if it's necessary then I think we've made a design error. The intention for base-passwd is to reduce the number of entries in the globally allocated space, and thus the number of mandatory entries in /etc/passwd and /etc/group, not to increase them. In the long term I'm hoping that we can find a way to have even some of the current mandatory entries merely allocated in a registry somewhere in /usr/share/base-passwd which adduser can use to create those entries on demand, although clearly that would need delicate transitional handling. Furthermore, the priority standard line appears to be entirely arbitrary. I assume it's designed to reduce the number of entries that must be allocated in base-passwd. However, there is no reason why problems encountered by Priority: standard packages and above (provided they aren't Essential or in adduser's dependency chain) should not also be encountered by Priority: optional and Priority: extra packages. Therefore, in solving these problems for the latter class of packages we can also solve it for the former. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#172436: Security concerns regarding browser proposal
On Sun, Aug 03, 2003 at 07:48:43PM -0400, Matt Zimmerman wrote: It might be a good idea to specify how quoting should be handled, both for shell metacharacters and format specifiers. Odd, I thought I'd mentioned http://www.dwheeler.com/browse/secure_browser.html in this bug, but evidently not. man implements the Compatible Secure BROWSER Definition from that page. It's about 50 lines of C, not counting an escape_shell() utility function. We could also go for the Alternative definition on the same page, which acknowledges that you probably need a helper script anyway to do the complicated Netscape/Mozilla stuff and ditches the % characters entirely. I don't have any strong feelings about which to use. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#203650: Poor recommendation in dpkg-statoverride section
On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote: So, let's break down what happens a bit: - dpkg unpacks the files, with their original permissions - postinst creates a user - postinst adds a statoverride to change the permissions The problem is that the user doesn't exist until after you unpack the files. Adding a statoverride here is a somewhat strange approach in its own right, ignoring such matters as the period between unpack and configure when permissions/owners are wrong. I suggest that this sequence would make more sense: - preinst creates a user - dpkg unpacks the files It's easier to understand and doesn't tread on the admin's toes as much. Note that dpkg stores users by name, not by uid. How should you ensure that the user in question exists on the system building the package? -- Colin Watson [EMAIL PROTECTED]
Bug#203650: Poor recommendation in dpkg-statoverride section
On Thu, Jul 31, 2003 at 01:16:35PM -0500, Adam Heath wrote: However, perhaps having fakeroot divert adduser, and when adduser is then run under fakeroot, a fakeroot-specific version would be used, that would communicate with faked, would be better. That's problematic too. You imply that build scripts should call adduser; and I don't think that merely building a package with real root privileges should modify the state of my system in major ways like adding new users. -- Colin Watson [EMAIL PROTECTED]
Bug#196367: debian-policy: clarify what to do about priority mismatches
On Mon, Jul 21, 2003 at 12:33:52PM +0200, Josip Rodin wrote: I propose this patch: --- policy.sgml~2003-07-21 12:17:53.0 +0200 +++ policy.sgml 2003-07-21 12:31:13.0 +0200 @@ -779,11 +779,24 @@ /p p - Packages must not depend on packages with lower priority + Packages should not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. /p + + p + Note that actual priorities of packages in the Debian archive + are set with the so-called override files, which are maintained + by the archive maintenance team. + footnote + In practice, this means that even if the package maintainer + uploads a fixed version of the package, the priority will + still be wrong in the Packages file until an ftpmaster goes + and changes the override. Thus, mass-filing bug reports + against individual packages for this is strongly discouraged. + /footnote + /p /sect /chapt Thanks for writing this patch. I agree that it documents current practice (and furthermore good practice, I believe) and second it. -- Colin Watson [EMAIL PROTECTED] pgpULXkIVlrNS.pgp Description: PGP signature
Re: Policy for 32-bit uids/gids?
On Wed, Jul 02, 2003 at 01:15:09PM -0500, Steve Langasek wrote: [Re-sent due to inability to properly address email.] Section 10.2 of policy currently describes uid and gid classes covering the range of 0-65535. This appears to no longer be comprehensive: on a current system running a 2.4.18 kernel and libc6 2.3.1-17, I'm able to assign 32-bit userids to accounts and reference these accounts in file ownerships, su to them, etc. Should Debian Policy be expanded to address this greatly increased range of available ids? This, together with your specific Samba proposal, sounds like a good idea, provided that the failures experienced by people with older kernels will be graceful and reasonably self-explanatory. Is anyone in a position to test this? When I say reasonable here, I do mean able to accomodate the ACL needs of a moderate-sized corporate WAN: the 6-64999 range /might/ be sufficient, if Debian were willing to allocate the whole thing to Samba. ;) You can't have all of it anyway. :) Reserved uids: uid | name | description --+---+--- 63434 | netplan | netplan 64000 | ftn | fidogate 64001 | mysql | mysql-server 64005 | tac-plus | tac-plus user 64010 | alias | qmail alias 64011 | qmaild| qmail daemon 64012 | qmails| qmail send 64013 | qmailr| qmail remove 64015 | qmailq| qmail queue 64016 | qmaill| qmail log 64017 | qmailp| qmail pw 64020 | asterisk | asterisk Reserved gids: gid | name | description --+---+--- 63434 | netplan | netplan 64000 | ftn | fidogate 64001 | mysql | mysql-server 64005 | tac-plus | tac-plus group 64010 | qmail | qmail 64020 | asterisk | asterisk (from /usr/share/doc/base-passwd/README) However, with the recent availability of 32-bit uids, this seems unnecessary. I would suggest allocating a 16-bit range out of the remaining (2^32-2^16) uids for Samba's use, and the same for gids; Provisionally, seems sensible. Should base-passwd be the registry for any similar high allocations in the future, or policy? I'm slightly concerned by how we're going to map onto other systems' uses of 32-bit uids here, since there will already be some. 0-99 and 6-64999 were reasonably obvious back in the day, but I don't have a feel for how big systems are allocating uids now. I would be inclined to start allocating from near the top, although perhaps not right at the top to avoid 2^32-1. Perhaps we should reserve something like 2^32-2^24 to 2^32-2^16 (255 chunks) so that we have space for anything else that may turn out to need similar large block allocations. I would like to see an initiative to agree this between multiple distributions via the LSB or similar with input from people running large systems, otherwise there'll probably be a horrible mess down the line. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#197835: [PROPOSAL]: integrated environments are allowed
[As Joey said recently in another discussion, please follow up to the bug, not to debian-policy.] On Wed, Jun 18, 2003 at 01:02:37AM -0400, Colin Walters wrote: On Tue, 2003-06-17 at 20:28, Colin Watson wrote: I think this is very bad. At the moment policy says that my EDITOR and PAGER variables have priority over what random programs think is a good idea, which I think is excellent. Yes...but the idea is if programs have a preferred version for a reason. Integrated environments like GNOME and KDE have very good reasons to prefer a particular editor, namely the one they ship with. *I* have very good reasons to prefer a particular editor, namely that I can use it with great facility and by and large find other editors uncomfortable and inflexible. Policy has this provision for a reason. If the editor is actually part of the other program, such as editing a text area in a web form directly in Mozilla, then I'd be willing to make an exception, but not otherwise. Use integrated environment's editor should be an option defaulting to off: note that newbies will not have $EDITOR set at all so this won't affect them, and many other people may choose to set $EDITOR in a context that doesn't apply to their whole X session so that programs launched from a window manager menu don't see it. This is fine. Again, this is simply codifying the status quo. Nothing in Debian should change. I honestly think that the status quo is broken, and therefore don't like the idea of writing it into policy (particularly in the manner of your proposal which effectively renders the paragraph in question completely ineffective because the exception is so general, but even beyond that). Is it really necessary to alienate lots of experienced users by insisting that GNOME and KDE are exceptions to all the rules whose consistent application has up until now made Debian a pleasure to use? Remember in particular that not everyone uses them as a complete environment. We have to face the fact that policy was written before there was anything like an integrated desktop environment. At the time Debian was just a random hodgepodge of unrelated software, and Debian's main task was trying to get it to work together in some sane fashion. But now we have software that's all *designed* to work together from the start. By imposing Debian's own view of how things should be done on it, we're breaking that which gives it value. But you're insisting that nobody might ever use it in a way different from what its designers expected. This is just not true in the real world: I've been known to fire up konqueror from a slightly GNOMEish environment, and it had better not try to spawn KDE's editor and KDE's pager for things. If I want it to do that, I'll unset $EDITOR and $PAGER. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: cdbs and Build-Depends-Indep
On Wed, Jun 18, 2003 at 02:11:06PM -0400, Colin Walters wrote: On Wed, 2003-06-18 at 13:36, Bill Allombert wrote: Not having the buildd installing tons of unneeded packages reduce build problems and make the logs more readable, Reduce build problems? How? The fewer packages you need to install, the less chance there is that one of them will be uninstallable and break your build. (I don't know how big a problem this is in practice, but it certainly does happen from time to time.) -- Colin Watson [EMAIL PROTECTED]
Re: cdbs and Build-Depends-Indep
On Wed, Jun 18, 2003 at 03:33:50PM -0400, Colin Walters wrote: On Wed, 2003-06-18 at 14:44, Colin Watson wrote: On Wed, Jun 18, 2003 at 02:11:06PM -0400, Colin Walters wrote: On Wed, 2003-06-18 at 13:36, Bill Allombert wrote: Not having the buildd installing tons of unneeded packages reduce build problems and make the logs more readable, Reduce build problems? How? The fewer packages you need to install, the less chance there is that one of them will be uninstallable and break your build. (I don't know how big a problem this is in practice, but it certainly does happen from time to time.) Then those packages are buggy and need to be fixed, obviously. Taking this argument farther, we could reduce build problems by including a known working copy of gcc in the source code of every package, too... Well, obviously; but reductio ad absurda notwithstanding, there's no need to invite more problems than we already have (http://bugs.debian.org/release-critical/, to name but 907). -- Colin Watson [EMAIL PROTECTED]
Bug#197835: [PROPOSAL]: integrated environments are allowed
[Moved discussion to the bug again rather than the -policy list. Set Mail-Followup-To: in an attempt to ensure that it stays there.] On Wed, Jun 18, 2003 at 11:11:48PM +0300, Richard Braakman wrote: On Wed, Jun 18, 2003 at 02:34:59PM -0400, Colin Walters wrote: I always have EDITOR set, but that doesn't mean I want to use that editor inside GNOME. I mostly have it set for all those terminal apps. Hmm. Maybe what we really need is a separate XEDITOR variable for starting an editor in a graphical environment. I think it's pretty common to want different editors in text and graphic modes. I was going to say much the same when I next got around to looking at this thread and apologizing for my earlier vehemence. :-) XEDITOR is a similar idea to the old EDITOR/VISUAL distinction, except that to a first approximation nobody cares about line-mode editors any more. However, the terminal/X distinction has become correspondingly more important. Having this as an environment variable rather than a piece of gconf configuration or what-have-you would make it possible for users to state their preference once in a way that can be applied consistently across not only GNOME and KDE but also other X applications that don't form part of an integrated environment. I haven't thought very much about Colin Walters' [1] points about editors as embeddable components yet, but if we had a distinct XEDITOR then we could probably support that quite sensibly by just using them when XEDITOR isn't set, since people whose only X applications are GNOMEish with an integrated editor component (for example) will have little reason to set it, even if they set EDITOR for terminal programs. I do take the point that nano in an xterm isn't the prettiest of defaults, but conversely I want a way to be able to tell all X applications that I want, say, gvim - or even 'pterm -e vi' - as my graphical editor without having to jump through hoops to do this for each desktop environment and each miscellaneous X application separately. We would also need a /usr/bin/x-editor alternative, with some scheme for agreeing priorities, and a sensible-x-editor program in debianutils. The other approach to the latter would be to modify sensible-editor to look at $DISPLAY ? la sensible-browser, but I think that would be unwise; you want the condition to be whether an X application is calling the editor, not whether you happen to be in X, since it's frequent for a user to want terminal-based programs to spawn terminal-based editors even if they happen to be running in X (say, mutt in an xterm). sensible-x-editor keys the decision on the nature of the caller, which is more appropriate. Thus, the policy for spawning an X editor could be: (1) check XEDITOR, (2) use integrated editor if available, (3) run sensible-x-editor (which might have 'xterm -e $EDITOR' as one of its fallback choices). Would this keep everyone happy? It's also worth noting that XEDITOR is not an entirely new idea, so we wouldn't be trailblazing out of the void here. Google for XEDITOR environment variable for some existing cases: for example, xdvi and ddd already support it. Or, for previous Debian discussion, http://lists.debian.org/debian-devel-0111/msg01595.html, where for what it's worth I disagree with Branden's followup suggestion that a wrapper that tests DISPLAY is sufficient, for the reasons stated above. I assume that the policy editors wouldn't be too happy to start recommending XEDITOR just yet, but if we agreed it informally now we could start getting it implemented in enough places to standardize it later. Where would be good places to start? Editor packages, debianutils, and some vanilla X mail and news programs like knews perhaps? [1] Damn, this is confusing. Maybe the two of us should avoid getting involved in the same discussions in the future. :-) -- Colin Watson [EMAIL PROTECTED]
Bug#197835: [PROPOSAL]: integrated environments are allowed
On Tue, Jun 17, 2003 at 07:51:00PM -0400, Colin Walters wrote: @@ -7349,11 +7352,13 @@ /p p - Thus, every program that launches an editor or pager must - use the EDITOR or PAGER environment variable to determine - the editor or pager the user wishes to use. If these - variables are not set, the programs file/usr/bin/editor/file - and file/usr/bin/pager/file should be used, respectively. + Thus, every program without an internal preference that + launches an editor or pager must use the EDITOR or PAGER + environment variable to determine the editor or pager the + user wishes to use. If these variables are not set, the + programs file/usr/bin/editor/file + and file/usr/bin/pager/file should be used, + respectively. /p p I think this is very bad. At the moment policy says that my EDITOR and PAGER variables have priority over what random programs think is a good idea, which I think is excellent. If programs get to pick a default that overrides my EDITOR and PAGER then it all degenerates into chaos. If what you really meant was that the order is as follows: * EDITOR/PAGER * program's preferred editor or pager * /usr/bin/editor or /usr/bin/pager ... then that would be slightly better; it dilutes the effectiveness of the editor and pager alternatives, but that might not be *too* bad. It's late here so I haven't fully thought it through. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: the 'build' debian/rules target
On Fri, Jun 13, 2003 at 01:40:34AM -0400, Colin Walters wrote: I don't quite understand the point of having the 'build' target be mandatory. dpkg-buildpackage requires it. You'd have to make it fail gracefully if the build target wasn't there, and probably get this into a stable release in order not to royally confuse users trying to build packages on stable. I'm not convinced this is a good idea, though; AIUI there are still architectures that have trouble with fakeroot (at least there are still build daemons that use sudo to gain root). Also, I find 'debian/rules build' a useful finger macro for when I just want to debug something small in a package and don't want to build the actual binary package (perhaps I'm on a system where I don't have root access to install the package anyway). I would be very disappointed if this no longer worked consistently. My problem with it is precisely what policy says: For some packages, notably ones where the same source tree is compiled in different ways to produce two binary packages, the `build' target does not make much sense. This confuses me. The build target makes perfect sense here; it just builds two temporary trees. With appropriate use of VPATH in the build system this is quite easy. The reason I bring this up is I am designing a new Debian build system, and it's hard for me to know what to do with it exactly. Please include the build target. It's useful for users as well. -- Colin Watson [EMAIL PROTECTED]
Re: Bug#196367: debian-policy: clarify what to do about priority mismatches
On Sat, Jun 07, 2003 at 10:02:14PM -0500, Manoj Srivastava wrote: On Sat, 7 Jun 2003 16:33:23 +0100, Colin Watson [EMAIL PROTECTED] said: Yes yes, we know all that. However, hundreds of release-critical bug reports cause very real practical problems for our release management processes, especially when they are unnecessary. Hundreds of RC bugs? Is this hyperbole, you you have the data to back that up? It is not hyperbole. By my count, http://ftp-master.debian.org/unmet-deps/unmet-unstable-i386.html shows 256 instances of packages depending on other packages with lower priority. I suppose some of them may collapse down to single bugs but it's still a lot. -- Colin Watson [EMAIL PROTECTED]
Bug#196367: debian-policy: clarify what to do about priority mismatches
On Sat, Jun 07, 2003 at 09:59:18PM -0500, Manoj Srivastava wrote: So fix the bug in the package, and clone it and assign the clone to ftp. It is a bug if the package has the wrong priority, and it is a bug if the override file needs fixing. Just because there are two locations where the fix needs to go in does not invalidate the bug. What real benefit (substantial enough to merit a release-critical bug) accrues from fixing the informational Priority: field in the package? The bug in the package should *not* be serious. That is my chief point. I doubt the ftp.debian.org team would be happy with 256 serious bugs filed there in preference to a single one saying that the override file needed to be sorted out before release either, but I'm not a member of that team so I will leave it to them to speak up. In other words, I would object to this change, since this would relax rules that allow me to just install base or standard packages from a CD, without needing extraneous packages, with very little benefit to anyone that I can see. I'm not suggesting that the rule be relaxed. I'm suggesting that we stop applying it in an ineffective place. Since the creation of the override file, the only role I can see for the Priority: field in a package's control file is to provide an initial suggestion to the ftpmasters as to the priority that should be set for that package. We've never considered mismatches between packages and the override file to be a serious bug. Arranging for all overrides to be consistent is a task that needs to be done before release, but one which can be done centrally, just like the process of deciding which packages should go on which CDs. We don't require all packages to carry an up-to-date control field saying which CD they should be on! Consider the move from managing task packages as metapackages to managing them as extra overrides for the Task: field, which was done to remove a roadblock in the release management process. Fixing priorities may occasionally require input from maintainers, but I do not believe that this is the norm, any more than deciding position on CDs routinely requires input from maintainers. -- Colin Watson [EMAIL PROTECTED]
Bug#196367: debian-policy: clarify what to do about priority mismatches
On Sat, Jun 07, 2003 at 03:40:37PM +0200, Bastian Blank wrote: On Fri, Jun 06, 2003 at 12:39:45PM -0700, Chris Waters wrote: And since we do make mistakes here, and since any change can cause a ripple-effect, making other packages suddenly violate this clause, and since violations of this are both quite harmless and hard-to-spot, how about we change it to not be a must? Then the ftp-masters can still try to ensure that it holds true, but people won't freak out about it. it will break the ability to just use packages with priority = standard and try to install one of them. Fortunately, this is not an amazingly big deal. Furthermore, it is *still* the case that the ftpmasters can and often do sort it out in one big pass without having to upload hundreds of packages. They already have tools to track priority mismatches. The point stands that uploading a package with a changed Priority: field does not by itself cause the Priority: field in the Packages file to change, so filing bugs against packages for this problem is useless. -- Colin Watson [EMAIL PROTECTED]
Re: Status of UTF-8 Debian changelogs
On Sat, Jun 07, 2003 at 04:59:29PM +0300, Dmitry Borodaenko wrote: On Thu, Jun 05, 2003 at 08:57:06PM -0400, Colin Walters wrote: JR the only thing that will change is that if someone complains at JR people who use UTF-8 in changelogs, a new retort will be JR available, THE POLICY MADE ME DO IT!!1!, or similar. CW Why would someone complain? I would complain. I am using KOI8-R terminal which can not display Latin-1 characters, Where did Latin-1 come into this? and it seems backward to me to mandate or even allow _usage_ of UTF-8 ahead of getting it _supported_ across the system. If you find yourself with a UTF-8 file, use a program which knows how to recode on the fly to your native encoding. Such programs are increasingly common. What do you lose here? Those who have fonts that can display the character in question will be able to do so; those who don't won't, but will see some reasonably obvious indicator like a ? or a filled-in square to show that the character is one they can't display. This is superior to the situation where those who don't have such fonts just see some gibberish. I'd rather have 7-bit ASCII changelogs: why Latin-1 users are privileged to use native spelling of their names, while Cyrillic and Kanji and other users have to resort to transliteration? They aren't so privileged. They may decide to do it anyway, but since the encoding of changelogs is not yet specified you currently take pot luck on anything outside 7-bit ASCII. I believe you've just contradicted yourself, anyway. Nobody wants to have to transliterate their name. I don't want to have to transliterate the names of people who help me with my packages when I credit them in the changelog; in some cases I may not even know how to transliterate their names correctly. UTF-8 allows me to spell their names correctly. At worst, a couple of characters may not be displayed properly for people using legacy encodings who don't have software that can recode for them, but if I'd artificially transliterated to 7-bit ASCII then nobody would get to see the correct spellings anyway. Since UTF-8 includes ASCII, all the technical content of my changelogs will still appear normally no matter what locale you're using, but suddenly it becomes possible for me to credit my contributors properly regardless of whether they come from Spain, Russia, or Japan. We're not talking about mandating the use of UTF-8 across the whole system here. We're talking about recommending its use in one particular case where it gives a small but real benefit, and where the consequences of getting it wrong are not very important (we can always go back and recode a few changelogs if some unforeseen badness results). Think of it as a safe experiment in advance of wider deployment of UTF-8 later on. Package maintainers who aren't set up for writing UTF-8 can always resort to transliteration into ASCII if need be. -- Colin Watson [EMAIL PROTECTED]
Bug#196367: debian-policy: clarify what to do about priority mismatches
On Fri, Jun 06, 2003 at 11:16:02PM +0200, Thomas Hood wrote: On Fri, 2003-06-06 at 21:39, Chris Waters wrote: On Fri, Jun 06, 2003 at 01:52:58PM +0100, Colin Watson wrote: Every so often, somebody encounters the bit of the policy manual that says: Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. Seeing the must, they then go and file a bunch of serious bugs. However, priorities are set by ftpmaster overrides, and, even if the maintainer uploads a fixed version of the package, the priority will still be wrong in the Packages file until an ftpmaster goes and changes the override. Thus, filing bugs against individual packages for this is basically a waste of time. The priority is changed in the override file, but I suppose it should be changed in the package source too. Ideally, but it really doesn't matter. It's a minor bug at best. Where is the reason to freak out? Freaking out is the wrong response to a bug report. A bug report is not an attack; it is a message, containing useful information. Yes yes, we know all that. However, hundreds of release-critical bug reports cause very real practical problems for our release management processes, especially when they are unnecessary. Policy is a tool (an essential one) to help us produce a better distribution; when it encourages people to impede the release process for little practical gain instead of getting the information to where it needs to go, it is not serving its purpose. Put another way, the bug is in the override file, not the package. It should therefore not be filed against the package. Doing so causes confusion and wastes time. -- Colin Watson [EMAIL PROTECTED]
Bug#196367: debian-policy: clarify what to do about priority mismatches
Package: debian-policy Version: 3.5.9.0 Severity: wishlist Every so often, somebody encounters the bit of the policy manual that says: Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. Seeing the must, they then go and file a bunch of serious bugs. However, priorities are set by ftpmaster overrides, and, even if the maintainer uploads a fixed version of the package, the priority will still be wrong in the Packages file until an ftpmaster goes and changes the override. Thus, filing bugs against individual packages for this is basically a waste of time. Instead of wasting a number of people's time and effort with lots of release-critical bugs, all the reporter needed to do was ask for the priorities of (ideally) a batch of packages to be changed. (I'm not sure in exactly what format ftpmaster would prefer reports like this - perhaps somebody could clarify - but I do know that hassling maintainers is a horribly ineffective way to get this job done.) I appreciate that in general policy isn't really the place for telling people how to go about getting particular problems fixed. However, when you try to tell somebody that actually the maintainers can't really do anything useful about the dozens of RC bugs they've just filed the response is invariably but policy said this was release-critical. I'd really like it to have some clarifying text that says something like this: Priorities are set by the archive maintainers and can be changed en masse, so filing release-critical bugs against individual packages is a poor way to report this class of problem. There were various discussions about this last year on debian-devel after a bout of mass-filing. Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#193748: debian-policy: gcc-3.3 no longer has varargs.h
On Sun, May 18, 2003 at 09:26:43PM +0200, Josip Rodin wrote: On Sun, May 18, 2003 at 08:33:01PM +0200, Bill Allombert wrote: In light of recent changes, I suggest that policy should instead say: How about we just remove the whole section? The software now makes it clear that the old stuff is a bug, and it's not like we need the Policy Manual to say fix the obvious bug. I concur, although perhaps it's still valuable to leave the libtermcap comments there since it (presumably) doesn't trigger a compiler warning in the same way. Maybe we should wait a bit before remove it ? See how many packages are affected, what feed back we get, etc... Well, that's my point. No packages should be affected -- in fact in sid I see only one dependency on termcap-compat, cmucl-source. I doubt there are many more sources using varargs.h, but I don't have numbers, so that might have to be investigated further. I filed this bug after running into xisp, which uses it. I don't recall encountering anything similar before, although of course the compiler change is very recent. -- Colin Watson [EMAIL PROTECTED]
Bug#193103: debian-policy: maybe say that programs that output HTML etc. should output valid HTML etc.
On Tue, May 13, 2003 at 07:15:04AM -0500, Graham Wilson wrote: On Tue, May 13, 2003 at 03:25:00AM +0100, Colin Watson wrote: On Mon, May 12, 2003 at 09:13:05PM -0500, Graham Wilson wrote: On Tue, May 13, 2003 at 01:25:52AM +0100, Colin Watson wrote: On Tue, May 13, 2003 at 04:20:03AM +0800, Dan Jacobson wrote: If there is a checklist for quality, then maybe say that programs that output HTML etc. should output valid HTML etc. E.g. one installs a program that makes a photo gallery of images, into a web page. But this page doesn't pass the HTML validator. Surely we don't need policy to say that a bug is a bug. It's quite clear that invalid HTML is a bug (maintainers may not think it's a particularly urgent bug, but it's a bug nevertheless). No need for policy to state the obvious. i think the author means _valid_ html, not just invalid html. I think you've read somebody's statements backwards, or something ... at any rate I'm confused now. oops. i probably should have read what i typed. i think the original poster of this bug means that it would be a bug for a program to produce html that doesnt validate according to the html dtd's. That was also my understanding. I quite agree that that's a bug, but I'm saying that the Debian Policy Manual doesn't need to spell out every single thing that we already know to be a bug. Policy covers decisions that have been taken in order that packages interoperate smoothly with the packaging system and with each other, and in order to ensure some degree of consistency across the system we provide. Sometimes it's also used to document a choice that the project has had to make between multiple technically valid alternatives. It is not there as a repository of admonitions against every possible thing which can go wrong with a package. The submitter of this bug has in the past (e.g. #177523) seemed to have the impression that if he finds a bug which has the potential to occur in more than one package, then policy should be amended to forbid that bug. I'm saying that when the bug is already obvious, such as claiming compliance with a standard when it doesn't pass that standard's validator, it is needless busy-work to amend policy, and doing so will serve absolutely no useful purpose. If people haven't noticed already that their HTML is invalid, a paragraph in policy is unlikely to make them notice any more quickly; and in any case the submitter is already fully entitled to file bugs about it regardless of whether policy says it's bad or not. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#193103: debian-policy: maybe say that programs that output HTML etc. should output valid HTML etc.
On Tue, May 13, 2003 at 04:20:03AM +0800, Dan Jacobson wrote: Package: debian-policy Version: 3.5.8.0 Severity: wishlist If there is a checklist for quality, then maybe say that programs that output HTML etc. should output valid HTML etc. E.g. one installs a program that makes a photo gallery of images, into a web page. But this page doesn't pass the HTML validator. Surely we don't need policy to say that a bug is a bug. It's quite clear that invalid HTML is a bug (maintainers may not think it's a particularly urgent bug, but it's a bug nevertheless). No need for policy to state the obvious. Cheers, -- Colin Watson [EMAIL PROTECTED]
