Bug#224509: Don't require a TTY during maintainer script execution
On Fri, Aug 7, 2009 at 19:43:29 -0700, Russ Allbery wrote: I think at this point, now that debconf is mandatory for all but essential packages, removing the guarantee of a controlling terminal is uncontroversial. This bug has been open for a while and I'd like to put it to bed. Here's proposed wording. I'm looking for feedback or seconds. Hi Russ, what does this change mean for essential packages that want to prompt the user when debconf isn't available? E.g. libc6.postinst tries to use debconf, and if that's not available and $DEBIAN_FRONTEND != noninteractive it prompts the user and reads stdin. I guess it's reasonable to expect dpkg frontends that don't provide a tty to set DEBIAN_FRONTEND, but maybe that should be spelled out? Cheers, Julien -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#224509: Don't require a TTY during maintainer script execution
Julien Cristau jcris...@debian.org writes: On Fri, Aug 7, 2009 at 19:43:29 -0700, Russ Allbery wrote: I think at this point, now that debconf is mandatory for all but essential packages, removing the guarantee of a controlling terminal is uncontroversial. This bug has been open for a while and I'd like to put it to bed. Here's proposed wording. I'm looking for feedback or seconds. what does this change mean for essential packages that want to prompt the user when debconf isn't available? E.g. libc6.postinst tries to use debconf, and if that's not available and $DEBIAN_FRONTEND != noninteractive it prompts the user and reads stdin. I guess it's reasonable to expect dpkg frontends that don't provide a tty to set DEBIAN_FRONTEND, but maybe that should be spelled out? It should be if that's something that packages can rely on. Does dpkg always set that if the session is not interactive? Otherwise, I would argue that the libc6.postinst script should instead run tty and check its exit status to determine whether there's a controlling terminal, and if not, take whatever non-interactive default it has. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
[ Moving to debian-policy ] Manoj Srivastava wrote: On Fri, Jul 31 2009, Emilio Pozuelo Monfort wrote: Manoj Srivastava wrote: We do not want to have different helper package start inventing a helper specific way of building ddebs, with no clear standard tha they are following. While archive coverage is nice, ensuring that a ddeb is properly defined, and that all the different ways of creating ddebs are consistent, should happen first. OK, so you mean I should document the ddeb format (which is that of .deb packages) and possibly include it in policy? That makes sense, if you want that I'll propose a patch for policy (note that udebs are not documented though). But regular packages are not creating udebs; and the whole idea behind automated ddeb creation is that the ./debian/rules file optionally creates ddebs. Since this affects the majority of packages, I think we need to be clear up front about ddeb creation. I've documented the .ddeb format in the wiki page [1] (DDeb Format, which is short since the format is basically that of .debs). Do we really need this to be documented in policy? Also, does anybody see a problem with adding .ddebs to the .changes file (in Files and *-Checksums), when they are not in debian/control? It seems to me like that's not a policy violation, but I could be wrong. Best regards, Emilio signature.asc Description: OpenPGP digital signature
Re: Automatic Debug Packages
On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote: [ Moving to debian-policy ] Manoj Srivastava wrote: On Fri, Jul 31 2009, Emilio Pozuelo Monfort wrote: Manoj Srivastava wrote: We do not want to have different helper package start inventing a helper specific way of building ddebs, with no clear standard tha they are following. While archive coverage is nice, ensuring that a ddeb is properly defined, and that all the different ways of creating ddebs are consistent, should happen first. OK, so you mean I should document the ddeb format (which is that of .deb packages) and possibly include it in policy? That makes sense, if you want that I'll propose a patch for policy (note that udebs are not documented though). But regular packages are not creating udebs; and the whole idea behind automated ddeb creation is that the ./debian/rules file optionally creates ddebs. Since this affects the majority of packages, I think we need to be clear up front about ddeb creation. I've documented the .ddeb format in the wiki page [1] (DDeb Format, which is short since the format is basically that of .debs). Do we really need this to be documented in policy? Not if that is all that is. So ddebs are just -dbg packages renamed to foo_version_arch.ddeb (you do not need ddeb in the name since they are called .ddebs.) The wiki does not seem to impose any additional rules on the ddebs (I assume that all the restrictions on a normal package still apply). Seems like then all that is needed is to build the package as normal, and after the dpkg invocation to build the package, one just adds a call to mv. This is simple. manoj The link to the wiki page was missing http://wiki.debian.org/AutomaticDebugPackages -- The meek shall inherit the earth, but not its mineral rights. Paul Getty 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
Re: Automatic Debug Packages
Manoj Srivastava wrote: On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote: I've documented the .ddeb format in the wiki page [1] (DDeb Format, which is short since the format is basically that of .debs). Do we really need this to be documented in policy? Not if that is all that is. So ddebs are just -dbg packages renamed to foo_version_arch.ddeb (you do not need ddeb in the name since they are called .ddebs.) dpkg doesn't know about filenames AFAICS. So you can't coinstall foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the -ddeb suffix. The wiki does not seem to impose any additional rules on the ddebs (I assume that all the restrictions on a normal package still apply). Right. Seems like then all that is needed is to build the package as normal, and after the dpkg invocation to build the package, one just adds a call to mv. This is simple. You can build a .ddeb manually, yes. However for some cases (e.g. packages using debhelper and building ELF binaries) a .ddeb will be automatically created (if none is created manually) and detached debugging symbols will be put there. I'll try to automatize other languages too, so that having full archive coverage is as simpler as possible. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Automatic Debug Packages
Emilio Pozuelo Monfort poch...@gmail.com writes: You can build a .ddeb manually, yes. However for some cases (e.g. packages using debhelper and building ELF binaries) a .ddeb will be automatically created (if none is created manually) and detached debugging symbols will be put there. I'll try to automatize other languages too, so that having full archive coverage is as simpler as possible. Could you explain a bit more about what merits you see in creating something that we call a different type of package rather than just listing debug packages in debian/control and building them as we do now and handling section debug specially in the archive software? Is it just the avoiding of the need to add a bunch of debian/control entries? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic Debug Packages
On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote: Manoj Srivastava wrote: On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote: I've documented the .ddeb format in the wiki page [1] (DDeb Format, which is short since the format is basically that of .debs). Do we really need this to be documented in policy? Not if that is all that is. So ddebs are just -dbg packages renamed to foo_version_arch.ddeb (you do not need ddeb in the name since they are called .ddebs.) dpkg doesn't know about filenames AFAICS. So you can't coinstall foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the -ddeb suffix. If we are going to enshrine ddebs into policy, we might as well teach dpkg about ddebs. The wiki does not seem to impose any additional rules on the ddebs (I assume that all the restrictions on a normal package still apply). Right. So why are we creating a whole new class of packages which dpkg does not know about, and which are substantially the same as the current -dbg packages? Is it to just reduce debian/control file bloat? Or to create debug packages whether or not the maintainer cooperates? The result appears to be to create a package automagically (the details appear fuzzy to me, perhaps I have not been paying attention), and add things to changes files even when the package is unknown to debian/control, so it is uploaded and processed by the archive scripts. All this seems to require large amounts of infrastructure work, why not add dpkg to the set of ddeb aware tools? Seems like then all that is needed is to build the package as normal, and after the dpkg invocation to build the package, one just adds a call to mv. This is simple. You can build a .ddeb manually, yes. However for some cases (e.g. packages using debhelper and building ELF binaries) a .ddeb will be automatically created (if none is created manually) and detached debugging symbols will be put there. I'll try to automatize other languages too, so that having full archive coverage is as simpler as possible. I don't use helper packages, including debhelper. So far, policy has not required me to, so if you want to put anything about ddebs in policy, there should be a route for people not using debhelper to contribute to debug packages in Debian, and not be relegated to the status of second class packages. manoj -- Tom's hungry, time to eat lunch. 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
Re: Automatic Debug Packages
Manoj Srivastava sriva...@debian.org writes: On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote: Manoj Srivastava wrote: On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote: I've documented the .ddeb format in the wiki page [1] (DDeb Format, which is short since the format is basically that of .debs). Do we really need this to be documented in policy? Not if that is all that is. So ddebs are just -dbg packages renamed to foo_version_arch.ddeb (you do not need ddeb in the name since they are called .ddebs.) dpkg doesn't know about filenames AFAICS. So you can't coinstall foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the -ddeb suffix. If we are going to enshrine ddebs into policy, we might as well teach dpkg about ddebs. Multiarch will require libfoo:i386 and libfoo:amd64 (for example). It might be simple to teach dpkg to use libfoo:ddeb:i386 and libfoo:ddeb:amd64 at the same time. Doesn't looks so nice though. You can build a .ddeb manually, yes. However for some cases (e.g. packages using debhelper and building ELF binaries) a .ddeb will be automatically created (if none is created manually) and detached debugging symbols will be put there. I'll try to automatize other languages too, so that having full archive coverage is as simpler as possible. I don't use helper packages, including debhelper. So far, policy has not required me to, so if you want to put anything about ddebs in policy, there should be a route for people not using debhelper to contribute to debug packages in Debian, and not be relegated to the status of second class packages. manoj He isn't asking you too. He is just saying that those 95% of packages using debhelper or cdbs or the like the ddeb can be build automatically without even having to change the source (or with just adding a single dh_make_ddebs). If you want to do it the hard way you always can. MfG Goswin -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#224509: Don't require a TTY during maintainer script execution
On Fri, 2009-08-07 at 19:43 -0700, Russ Allbery wrote: I think at this point, now that debconf is mandatory for all but essential packages, removing the guarantee of a controlling terminal is uncontroversial. This bug has been open for a while and I'd like to put it to bed. Here's proposed wording. I'm looking for feedback or seconds. Seconded. Cheers, Andrew. diff --git a/policy.sgml b/policy.sgml index 27deaa7..bf99884 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3529,15 +3529,17 @@ Package: libc6 headingControlling terminal for maintainer scripts/heading p - The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - Because these scripts may be executed with standard output - redirected into a pipe for logging purposes, Perl scripts - should set unbuffered output by setting tt$|=1/tt so - that the output is printed immediately rather than being - buffered. + Maintainer scripts are not guaranteed to run with a controlling + terminal and may not be able to interact with the user. They + must be able to fall back to noninteractive behavior if no + controlling terminal is available. Maintainer scripts that + prompt via a program conforming to the Debian Configuration + Management Specification (see ref id=maintscriptprompt) may + assume that program will handle falling back to noninteractive + behavior. /p /sect + sect id=exitstatus headingExit status/heading @@ -9397,9 +9399,9 @@ END-INFO-DIR-ENTRY /p p - The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - See ref id=controllingterminal. + The maintainer scripts are not guaranteed to run with a + controlling terminal and may not be able to interact with + the user. See ref id=controllingterminal. /p /item -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ andrew (AT) morphoss (DOT) com+64(272)DEBIAN Your nature demands love and your happiness depends on it. signature.asc Description: This is a digitally signed message part
Bug#224509: Don't require a TTY during maintainer script execution
On Fri, Aug 07, 2009 at 07:43:29PM -0700, Russ Allbery wrote: I think at this point, now that debconf is mandatory for all but essential packages, removing the guarantee of a controlling terminal is uncontroversial. This bug has been open for a while and I'd like to put it to bed. Here's proposed wording. I'm looking for feedback or seconds. Should it be spelled out here that in the case of questions that don't have a reasonable default answer (priority high or higher), an acceptable action for the maintainer script to take when running non-interactively is to abort? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#224509: Don't require a TTY during maintainer script execution
Steve Langasek vor...@debian.org writes: On Fri, Aug 07, 2009 at 07:43:29PM -0700, Russ Allbery wrote: I think at this point, now that debconf is mandatory for all but essential packages, removing the guarantee of a controlling terminal is uncontroversial. This bug has been open for a while and I'd like to put it to bed. Here's proposed wording. I'm looking for feedback or seconds. Should it be spelled out here that in the case of questions that don't have a reasonable default answer (priority high or higher), an acceptable action for the maintainer script to take when running non-interactively is to abort? That's probably not a bad idea. I was thinking about that, and wasn't sure, but if you also feel the same way, we should probably say something. I'm also not sure that I was right in my previous message about using the exit status of tty, since it still does make sense to prompt if run via ssh host aptitude upgrade. But I don't know how to detect that case as different from a truly non-interactive install. -- 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
