Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Mon, Aug 17, 2009 at 04:18:13PM -0700, Steve Langasek wrote [edted]: I would suggest disallowing example entries altogether; let packages use the '#off#' syntax instead. Or is there some reason I'm missing why we would want to support so many different ways for packages to add lines to update-inetd? I'm all for simplicity, so by all means let's disallow example entries. - If a package wants to install an example entry into `/etc/inetd.conf', - the entry must be preceded with exactly one hash character (`#'). - Such lines are treated as commented out by user by the - `update-inetd' script and are not changed or activated during package - updates. + Lines preceded with exactly one hash character (`#') are treated as + commented out by user by the `update-inetd' script and must not be + changed or activated during package updates. The case of example entries is beyond the scope of policy. update-inetd can easily get a new ``--add-disabled'' switch (which will be identical to ``--add'' except for prefixing the entry with '#off# '). -S -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
Serafeim Zanikolas ser...@hellug.gr writes: On Mon, Aug 17, 2009 at 04:18:13PM -0700, Steve Langasek wrote [edted]: I would suggest disallowing example entries altogether; let packages use the '#off#' syntax instead. Or is there some reason I'm missing why we would want to support so many different ways for packages to add lines to update-inetd? I'm all for simplicity, so by all means let's disallow example entries. - If a package wants to install an example entry into `/etc/inetd.conf', - the entry must be preceded with exactly one hash character (`#'). - Such lines are treated as commented out by user by the - `update-inetd' script and are not changed or activated during package - updates. + Lines preceded with exactly one hash character (`#') are treated as + commented out by user by the `update-inetd' script and must not be + changed or activated during package updates. The case of example entries is beyond the scope of policy. update-inetd can easily get a new ``--add-disabled'' switch (which will be identical to ``--add'' except for prefixing the entry with '#off# '). I agree with this in principle, but adding that as a must is going to make a fair number of packages instantly buggy. We should have some sort of transition plan and advance warning for packages that install example inetd entries, I think. It shouldn't be too difficult to detect calls to update-inetd where the service is commented out. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Tue, Aug 18, 2009 at 01:43:47AM +0100, Roger Leigh wrote [edited]: I would really rather we went with the proposal I put forward in this thread: http://lists.debian.org/debian-devel/2009/03/msg00496.html in this message: http://lists.debian.org/debian-devel/2009/03/msg00573.html Sorry too many downsides: - too disruptive, too much work - how are you going to keep track of user-policy along the lines of I don't want ftp enabled no matter what packages are installed in the future? - you'll have to re-implement update-inetd from scratch, except that now the functionality will be spread all over the place - you need to ship fragments for every supported format Having read several criticisms of update-inetd, I still think that we're better off fixing it than starting from scratch (please don't spend any time trying to convince me otherwise; if you feel like it, let's discuss how to fix it's problems than hypothetical alternative approaches). update-inetd has many open bugs: - it _is_ actually buggy (most notably #510406) - the documentation is not in-your-face explicit about user-disabled entries being preceded with only one '#'; '##' won't do, '# ' or anything else won't do either - policy doesn't help (hence this bug) and it's silent on how update-inetd should deal with service entries that are commented out with neither '#' nor '#off#' (how about adding a lintian warning for these cases?) - perhaps due to policy and the --comment-chars misfeature, maintainer scripts might not always do the right thing (meaning, never disable a service with anything but the default comment-chars) -S -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Tagging bugs
Processing commands for cont...@bugs.debian.org: package debian-policy Limiting to bugs with field 'package' containing at least one of 'debian-policy' Limit currently set to 'package':'debian-policy' user debian-pol...@packages.debian.org Setting user to debian-pol...@packages.debian.org (was sriva...@debian.org). usertag 541872 = normative issue Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf There were no usertags set. Usertags are now: normative issue. severity 541872 wishlist Bug #541872 [debian-policy] debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf Severity set to 'wishlist' from 'normal' severity 299007 wishlist Bug #299007 [debian-policy] base-files: Insecure PATH in /root/.profile Bug #538392 [debian-policy] Should /usr/local be writable by group staff? Severity set to 'wishlist' from 'normal' Severity set to 'wishlist' from 'normal' -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Tue, Aug 18, 2009 at 08:02:33PM +0200, Serafeim Zanikolas wrote: On Tue, Aug 18, 2009 at 01:43:47AM +0100, Roger Leigh wrote [edited]: I would really rather we went with the proposal I put forward in this thread: http://lists.debian.org/debian-devel/2009/03/msg00496.html in this message: http://lists.debian.org/debian-devel/2009/03/msg00573.html Sorry too many downsides: - too disruptive, too much work Not really, it would be the same as any transition. Just two simple changes to each package. And since both old and new mechanisms are in place during the transition, the length of time isn't too important. iwj, who was originally involved with update-inetd, agreed that this was a good plan. In fact, it can really just be one change, since the new tool can just be run as a dpkg file trigger, so there's no strict requirement to remove use of update-inetd to complete the transition. - how are you going to keep track of user-policy along the lines of I don't want ftp enabled no matter what packages are installed in the future? Just edit the entry for the package. If you read the original threads, you would have seen that since everything becomes a conffile, this would be managed entirely via dpkg conffile handling. You'd just have the equivalent of enabled=false in the file, and rerun update-inetd. This is achieved simply by having packages providing the service install the config fragment by the same name. The idea of preserving that particular configuration choice is a bit suspect however. If you don't want a service enabled, you don't install it. Non-inetd-using services don't function this way, so this is a rather odd requirement. - you'll have to re-implement update-inetd from scratch, except that now the functionality will be spread all over the place No, it's in a single place. And it's idempotent, and robust. This re-implementation will be dead simple. It just reads each file in and spits out a generated inetd.conf. Nothing else. This is why we gain idempotency and robustness: there's no editing of the entries; we let the dpkg conffile mechanism handle everything else. As a one-time transition mechanism, we could read the old inetd.conf and update the fragments with that state so the inetd configuration is carried over. Again, that's pretty trivial. - you need to ship fragments for every supported format No, the single tool can generate all supported formats in a single run. The fragments would be a superset of the configuration for all currently available inetds, including xinetd. The tool would read them all in, and generate a set of inetd configuration files under /var, one per format supported. Realistically, there's basically just two: inetd and xinetd. We could support variants on the inetd format to support the various minor extensions and features of individual inetds. Each inetd implementation would then be patched to read the appropriate configuration file. Having read several criticisms of update-inetd, I still think that we're better off fixing it than starting from scratch (please don't spend any time trying to convince me otherwise; if you feel like it, let's discuss how to fix it's problems than hypothetical alternative approaches). Unfortunately, the whole concept of update-inetd is horribly broken. It needs scrapping. There's a reason why no one has fixed it in years, it's due to the fact that its problems are design faults. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
Package: debian-policy Version: 3.8.3.0 Severity: wishlist User: debian-pol...@packages.debian.org Usertags: normative issue Hi, Currently, there is some ambiguity in the areas of version numbering, debian_revision, native packages, and requirement for a diff.gz/orig.tar.gz files in a source package. Also, currently policy does not carve out version name spaces for NMU's (native and non-native packages), for version numbers for binary only uploads, though there are well established practices for these use cases. To recap, this is what is incontrovertibly stated in policy: ,[ §5.6.12: `Version' ] | The format is: | [epoch`:']upstream_version[`-'debian_revision] | upstream_version | SNIP | The comparison behavior of the package management system with | respect to the upstream_version is described below. The | upstream_version portion of the version number is mandatory. | | The upstream_version may contain only alphanumerics[1] and the | characters `.' `+' `-' `:' `~' (full stop, plus, hyphen, colon, | tilde) and should start with a digit. If there is no | debian_revision then hyphens are not allowed; if there is no | epoch then colons are not allowed. | | debian_revision | This part of the version number specifies the version of the | Debian package based on the upstream version. It may contain | only alphanumerics and the characters `+' `.' `~' (plus, full | stop, tilde) and is compared in the same way as the | upstream_version is. | | It is optional; if it isn't present then the upstream_version | may not contain a hyphen. This format represents the case where | a piece of software was written specifically to be turned into a | Debian package, and so there is only one debianisation of it | and therefore no revision indication is required. ` Additionally, § 5.6.21. `Files' mentions that the .dsc will contain a diff.gz if applicable § C.1.1. `dpkg-source' states that it creates a diff.gz if appropriate, and looks at the diff.gz while extracting if applicable. ,[ § C.3. Source packages as archives ] | Original source archive - `package_upstream-version.orig.tar.gz' | This is a compressed (with `gzip -9') `tar' file containing the | source code from the upstream authors of the program. | | Debianisation diff - `package_upstream_version-revision.diff.gz' | This is a unified context diff (`diff -u') giving the changes | which are required to turn the original source into the Debian | source. These changes may only include editing and creating | plain files. The permissions of files, the targets of symbolic | links and the characteristics of special files or pipes may not | be changed and no files may be removed or renamed. | | All the directories in the diff must exist, except the `debian' | sub-directory of the top of the source tree, which will be created | by `dpkg-source' if necessary when unpacking. | | The `dpkg-source' program will automatically make the | `debian/rules' file executable (see below). | | If there is no original source code - for example, if the package is | specially prepared for Debian or the Debian maintainer is the same as | the upstream maintainer - the format is slightly different: then there | is no diff, and the tar file is named `package_version.tar.gz', and | preferably contains a directory named `package-version'. ` Given these, I read this as letting the tools rely on the following invariants, even though these are not explicitly spelled out in so many words in policy: 1) If there is a - in the version number, then the package is non-native a) the upstream version is the part of the string until the last '-' in the version number b) there is a .orig.tar.gz and c) diff.gz referenced in the .dsc 2) If there is no '-' in the version number, then the package is a debian native package a) there is no debian revision, all the version number is the upstream version number b) there is a tar.gz and no diff.gz in the .dsc file -- Given that, it would be nice we could carve out a space in the version numbering that would help us distinguish NMU's and binary uploads. 1) dch --nmu adds +nmu1 for native packages 2) +nmuX is already supported by devscripts and lintian. 3) the developers reference also advocates adding +codename\d+. It also advocates using exactly the same tar.gz file as already in the archive. 4) this is how debhelper, cdbs, and my packaging scripts handle it. Please also look at the discussion below, which led to
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
I like this proposal, thanks for ignoring my request to not write about alternatives ;) I'll take some time to think about it and read up on triggers/etc. I might bug you in private about this as I think we're getting off-topic here. -S -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Tue, 18 Aug 2009, Manoj Srivastava wrote: Given these, I read this as letting the tools rely on the following invariants, even though these are not explicitly spelled out in so many words in policy: 1) If there is a - in the version number, then the package is non-native a) the upstream version is the part of the string until the last '-' in the version number b) there is a .orig.tar.gz and c) diff.gz referenced in the .dsc 2) If there is no '-' in the version number, then the package is a debian native package a) there is no debian revision, all the version number is the upstream version number b) there is a tar.gz and no diff.gz in the .dsc file (1) is not necessarily true in the case of NMUs of native packages.[1] The only way to tell if a package is native or not is to inspect the .dsc. [So long as the as-yet-to-be-proposed wording is clear on this, it should be a big deal.] That said, the rest looks reasonable, but it would probably be useful to make sure that we're actually representing current practice. Don Armstrong 1: I've personally made a at least one of these before I was aware of the +nmu1 option. -- Three little words. (In descending order of importance.) I love you -- hugh macleod http://www.gapingvoid.com/graphics/batch35.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Tue, Aug 18 2009, Don Armstrong wrote: On Tue, 18 Aug 2009, Manoj Srivastava wrote: Given these, I read this as letting the tools rely on the following invariants, even though these are not explicitly spelled out in so many words in policy: 1) If there is a - in the version number, then the package is non-native a) the upstream version is the part of the string until the last '-' in the version number b) there is a .orig.tar.gz and c) diff.gz referenced in the .dsc 2) If there is no '-' in the version number, then the package is a debian native package a) there is no debian revision, all the version number is the upstream version number b) there is a tar.gz and no diff.gz in the .dsc file (1) is not necessarily true in the case of NMUs of native packages.[1] The only way to tell if a package is native or not is to inspect the .dsc. [So long as the as-yet-to-be-proposed wording is clear on this, it should be a big deal.] I understand today that perhaps NMU's of native packages do not follow 1. However, consider this: 1) dch --nmu adds +nmu1 for native packages 2) +nmuX is already supported by devscripts and lintian. 3) the developers reference also advocates adding +codename\d+. It also advocates using exactly the same tar.gz file as already in the archive. 4) this is how debhelper, cdbs, and my packaging scripts handle it. Please also look at the discussion below, which led to developers reference changing its recommendation. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437392 That link states that debhelper, cdbs, and (ahem) my scripts all use the same convention for distinguishing native packages from non native ones, namely, the presence of a hyphen in the version number. I am suggesting, in this case, we *make* policy to explicitly adopt the design that the dev-ref, devscripts, lintian, etc all currently espouse; with perhaps the proviso that this be a should or perhaps recommended bahaviour for a while. I consider having to look into a .dsc file to see whether a package is a native NMU or a non-native package to be a flaw large enough to warrant making policy here, especially since debhelper and cdbs and devscripts all follow this. As far as policy is concerned, there is a strong indication that if there is a - in the version, there is an upstream package, and there is a debian revision, and there are also indications that a non-native package needs to have orig.tar.gz/diff.gz. Making a package seem like it is native and non native based on whether the last upload was a NMU is bad, and it contradicts both policy on version number format and the def ref recommendations. That said, the rest looks reasonable, but it would probably be useful to make sure that we're actually representing current practice. Given that devscripts, lintian, debhelper, cdbs and the dev-ref all advocate or implement +nmu\d+, I have tried to do so. Having said that, there are a lot of packages that seem to still use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this policy change as a 'recommends', and letting lintian warn about the version number. __ egrep '^Version: ' /var/lib/dpkg/available | wc -l 26797 __ egrep '^Version: ' /var/lib/dpkg/available | perl -nle 'm/\-\d+\.\d+$/ print' | wc -l 2127 Of course, the majority of these packages are not native packages, but it is hard to tell which are which. manoj -- Cynicism is an unpleasant way of saying the truth. Lillian Hellman Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Tue, Aug 18 2009, Don Armstrong wrote: On Tue, 18 Aug 2009, Manoj Srivastava wrote: Given these, I read this as letting the tools rely on the following invariants, even though these are not explicitly spelled out in so many words in policy: 1) If there is a - in the version number, then the package is non-native a) the upstream version is the part of the string until the last '-' in the version number b) there is a .orig.tar.gz and c) diff.gz referenced in the .dsc 2) If there is no '-' in the version number, then the package is a debian native package a) there is no debian revision, all the version number is the upstream version number b) there is a tar.gz and no diff.gz in the .dsc file (1) is not necessarily true in the case of NMUs of native packages.[1] The only way to tell if a package is native or not is to inspect the .dsc. [So long as the as-yet-to-be-proposed wording is clear on this, it should be a big deal.] I understand today that perhaps NMU's of native packages do not follow 1. However, consider this: 1) dch --nmu adds +nmu1 for native packages 2) +nmuX is already supported by devscripts and lintian. 3) the developers reference also advocates adding +codename\d+. It also advocates using exactly the same tar.gz file as already in the archive. 4) this is how debhelper, cdbs, and my packaging scripts handle it. Please also look at the discussion below, which led to developers reference changing its recommendation. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437392 That link states that debhelper, cdbs, and (ahem) my scripts all use the same convention for distinguishing native packages from non native ones, namely, the presence of a hyphen in the version number. I am suggesting, in this case, we *make* policy to explicitly adopt the design that the dev-ref, devscripts, lintian, etc all currently espouse; with perhaps the proviso that this be a should or perhaps recommended bahaviour for a while. I consider having to look into a .dsc file to see whether a package is a native NMU or a non-native package to be a flaw large enough to warrant making policy here, especially since debhelper and cdbs and devscripts all follow this. As far as policy is concerned, there is a strong indication that if there is a - in the version, there is an upstream package, and there is a debian revision, and there are also indications that a non-native package needs to have orig.tar.gz/diff.gz. Making a package seem like it is native and non native based on whether the last upload was a NMU is bad, and it contradicts both policy on version number format and the def ref recommendations. That said, the rest looks reasonable, but it would probably be useful to make sure that we're actually representing current practice. Given that devscripts, lintian, and the dev-ref all advocate or implement +nmu\d+, and that debhelper and cdbs look at the hyphen for determining native vs non-native, I have tried to do so. I think the proposed practice is strictly better than not specifying any conventions, and where possible, Ihave tried to stick to best practices as documented in the dev-ref to base policy on. Having said that, there are a lot of packages that seem to still use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this policy change as a 'recommends', and letting lintian warn about the version number. __ egrep '^Version: ' /var/lib/dpkg/available | wc -l 26797 __ egrep '^Version: ' /var/lib/dpkg/available | perl -nle 'm/\-\d+\.\d+$/ print' | wc -l 2127 Of course, the majority of these packages are not native packages, but it is hard to tell which are which. manoj -- Cynicism is an unpleasant way of saying the truth. Lillian Hellman Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
Roger Leigh rle...@codelibre.net writes: The initial work that needs doing is defining a suitable file format. A simple key=value or Key: Value scheme would probably be sufficient if there's only one service per file. Alternatively, the xinetd format is /currently/ the superset, but that's perhaps not flexible enough for the future since we're then tied into being compatible with that single implementation. I'd love to see a solution that would involve packages shipping xinetd fragments and stripping those fragments down for inetd if inetd were in use instead. The xinetd syntax is more expressive and is used by other distributions, so we wouldn't be inventing something new that's specific to Debian. And then xinetd wouldn't have to go through update-inetd and could just use the fragments directly, which would resolve that integration problem in what I think is a cleaner way. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
