Re: Install-info transition, review time
On Mon, 13 Apr 2009, Norbert Preining wrote: How do we proceed now with that? As said in a different email some weeks ago, only ~50 of around 580 total info files fail when called with ginstall-info. We should file those bugs now with an explanation of the problem. You should also upload texinfo/i-i now given that it has to go through NEW. There are some things some well experienced DD could take a look at: - install-info binary package: . /usr/sbin/update-info-dir a script I have written that recreates the dir file from all the installed info files. Not very intelligent, but it does its job. Review would be fine . /usr/bin/install-info trivial script, the warning messages can be discussed - dpkg binary package: . /usr/sbin/install-info a binary (C code) AFAIR to deduce the calling way, Raphael can tell you were to get the code http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/install-info Ok, hope that we get this going ... Yeah, I waited your come-back, I didn't want to start this while you were not available. We haven't had much feedback but I hope I cleared the problems seen by Steve with my explanations on how they were already adressed. The only problem is that britney ignores Breaks and that the release team might have to migrate info browsers together with the newer dpkg to avoid uninstallable combinations in testing. (Bccing release team for this, see http://lists.debian.org/debian-devel/2009/03/msg01484.html for the start of the discussion) Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install-info transition, review time
On Di, 14 Apr 2009, Norbert Preining wrote: - Do we need any special control entries (breaks, suggests, etc) in the new package? (current debian/control attached) Forgot that one, and found that there is a bug in the current control file, under package install-info I still have Replaces: dpkg (= 1.14.25) which is not true, because we do not ship /usr/sbin/install-info in the install-info package, but in /usr/bin. I will prepare a new package and also merge all the experimental changelog entries, and upload to p.d.o. - upload to experimental or sid? And after that is cleared also to exp|sid. Best wishes Norbert --- Dr. Norbert Preining prein...@logic.atVienna University of Technology Debian Developer prein...@debian.org Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- The suit into which the man's body had been stuffed looked as if it's only purpose in life was to demonstrate how difficult it was to get this sort of body into a suit. --- Douglas Adams, The Hitchhikers Guide to the Galaxy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install-info transition, review time
Hi all, On Di, 14 Apr 2009, Raphael Hertzog wrote: We should file those bugs now with an explanation of the problem. You should also upload texinfo/i-i now given that it has to go through NEW. Ok, still a review from someone else would be nice. Before uploading two questions: - Do we need any special control entries (breaks, suggests, etc) in the new package? (current debian/control attached) - upload to experimental or sid? Best wishes Norbert --- Dr. Norbert Preining prein...@logic.atVienna University of Technology Debian Developer prein...@debian.org Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- GRETNA GREEN (adj.) A shade of green which cartoon characters dangle over the edge of a cliff. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install-info transition, review time
Hi all, after return from hardware-VAC and fixing grave texlive bugs and and and here are now some remarks on the i-i transition. On Di, 24 Mär 2009, Raphael Hertzog wrote: http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo Please review and raise any suggestions if you have any. There has been some extensive discussion on -dpkg already that you can read to understand the choices made: http://lists.debian.org/debian-dpkg/2009/03/msg00019.html As mentioned, it would be nice to have that posted here, but unfortunately the discussion and the transition plan are already sooo long and I guess nobody will read it. The Wiki collects the most important things. On Do, 26 Mär 2009, Neil Williams wrote: * install-info operations will all then happen in triggers, not directly via maintainer scripts. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518737#12 The plan is always to get rid of install-info inside dpkg, so asking us for this change is not the right long-term solution. (And contrary to update-alternatives, I don't think such a change make sense) I would really suggest that you design a solution that doesn't require the postinst snippet at all. A simple solution could be: - have a package install-info register a file trigger on /usr/share/install-info/ - have other packages provide a .install-info file in that directory that tells how install-info should be called - add a dh_installinfo helper to automatize the installation of this file - have info readers depend on the new install-info package The experimental package of texinfo(source) I have prepared deb(-src) http:/people.debian.org/~preining/TeX/ i-i/ do it a bit differently by directly declaring interest on /usr/share/info, and not adding another file layer. That allows completion of all *current* postinst files calling install-info. The wrapper in /usr/bin and /usr/sbin will just warn and do nothing. That way packages will still work as they are now, the /usr/share/info/dir file will be updated anyway using the new method, and as soon as a new debhelper is uploaded the install-info calls will disappear slowly from the maintainer scripts. Triggers will replace such maintainer script calls, making info documents no different to manpages in terms of their installation, hence no need for any support from Essential and triggers will simply not be called if install-info is not installed. See above. Exactely that is the goal IIRC the remaining install-info script is to provide support until all the packages using maintainer scripts calls migrate to using triggers for their info documents. /usr/sbin/install-info for maintainer scripts calling install-info with full path /usr/bin/install-info for maintainer scripts that still call install-info (not rebuild with new debhelper) and for doing the right thing when an admin calls it in the intention to call GNU install-info How do we proceed now with that? As said in a different email some weeks ago, only ~50 of around 580 total info files fail when called with ginstall-info. There are some things some well experienced DD could take a look at: - install-info binary package: . /usr/sbin/update-info-dir a script I have written that recreates the dir file from all the installed info files. Not very intelligent, but it does its job. Review would be fine . /usr/bin/install-info trivial script, the warning messages can be discussed - dpkg binary package: . /usr/sbin/install-info a binary (C code) AFAIR to deduce the calling way, Raphael can tell you were to get the code Ok, hope that we get this going ... Best wishes Norbert --- Dr. Norbert Preining prein...@logic.atVienna University of Technology Debian Developer prein...@debian.org Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- NETHER POPPLETON (n. obs.) A pair of P.J.Proby's trousers. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install-info transition, review time
On Tue, Mar 24, 2009 at 12:05:43PM +0100, Raphael Hertzog wrote: the dpkg team and the texinfo maintainer have laid out a plan to get rid of dpkg /usr/sbin/install-info and start relying on GNU's install-info when needed. This will involve some work to transition properly. We have described our plan here: http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo It would be nice if the details were posted to the mailing list instead of referencing a wiki. * dpkg ships a new /usr/sbin/install-info that will call /usr/bin/install-info with the same arguments. It also warns the user if called with an absolute path. Dpkg also contains Breaks against old versions of all info-browsers that do not depend on install-info. I don't like the sound of this. Why is it necessary to provide /usr/sbin/install-info? I assume this is out of concern that some packages will be calling install-info with an explicit path, but that's been contrary to Policy for years (Programs called from maintainer scripts should not normally have a path prepended to them, Policy 6.1) and I don't see any evidence looking at my local systems that install-info is being used incorrectly. I don't think there should be an extra install-info in the path without a clearer rationale. Also, is the new dpkg going to Pre-Depend: on this new install-info package? If not, what does this /usr/sbin/install-info wrapper script do when called and /usr/bin/install-info is absent? Packages currently call install-info from their maintainer scripts unconditionally, because it's provided by an Essential package. Please review and raise any suggestions if you have any. There has been some extensive discussion on -dpkg already that you can read to understand the choices made: http://lists.debian.org/debian-dpkg/2009/03/msg00019.html Given that install-info is codified in Policy, I think this plan needs to be vetted via the policy process and include specific changes to the language in Policy, prior to moving forward on implementation. -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install-info transition, review time
On Thu, 26 Mar 2009 00:00:51 -0700 Steve Langasek vor...@debian.org wrote: On Tue, Mar 24, 2009 at 12:05:43PM +0100, Raphael Hertzog wrote: the dpkg team and the texinfo maintainer have laid out a plan to get rid of dpkg /usr/sbin/install-info and start relying on GNU's install-info when needed. This will involve some work to transition properly. We have described our plan here: http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo or: Proposal to replace Debian's install-info with GNU's install-info (via triggers) http://lists.debian.org/debian-dpkg/2009/03/msg00019.html (which is where this all started) and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518737 which is why it restarted now. It would be nice if the details were posted to the mailing list instead of referencing a wiki. * dpkg ships a new /usr/sbin/install-info that will call /usr/bin/install-info with the same arguments. It also warns the user if called with an absolute path. Dpkg also contains Breaks against old versions of all info-browsers that do not depend on install-info. * install-info operations will all then happen in triggers, not directly via maintainer scripts. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518737#12 The plan is always to get rid of install-info inside dpkg, so asking us for this change is not the right long-term solution. (And contrary to update-alternatives, I don't think such a change make sense) I would really suggest that you design a solution that doesn't require the postinst snippet at all. A simple solution could be: - have a package install-info register a file trigger on /usr/share/install-info/ - have other packages provide a .install-info file in that directory that tells how install-info should be called - add a dh_installinfo helper to automatize the installation of this file - have info readers depend on the new install-info package Opinions ? Cheers, Raphaël Hertzog Also, is the new dpkg going to Pre-Depend: on this new install-info package? If not, what does this /usr/sbin/install-info wrapper script do when called and /usr/bin/install-info is absent? Packages currently call install-info from their maintainer scripts unconditionally, because it's provided by an Essential package. Triggers will replace such maintainer script calls, making info documents no different to manpages in terms of their installation, hence no need for any support from Essential and triggers will simply not be called if install-info is not installed. IIRC the remaining install-info script is to provide support until all the packages using maintainer scripts calls migrate to using triggers for their info documents. There were also extensive discussions on the texinfo list but Norbert is currently on (partially hardware enforced) VAC. http://lists.debian.org/debian-tex-maint/2009/03/msg00023.html Please review and raise any suggestions if you have any. There has been some extensive discussion on -dpkg already that you can read to understand the choices made: http://lists.debian.org/debian-dpkg/2009/03/msg00019.html Given that install-info is codified in Policy, I think this plan needs to be vetted via the policy process and include specific changes to the language in Policy, prior to moving forward on implementation. There probably should have been more on the wiki page about the earlier discussions. I'll try and update it over the weekend, unless someone else is able to do it earlier. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpUDsJnawt5s.pgp Description: PGP signature
Re: Install-info transition, review time
On Thu, Mar 26, 2009 at 07:21:15AM +, Neil Williams wrote: Also, is the new dpkg going to Pre-Depend: on this new install-info package? If not, what does this /usr/sbin/install-info wrapper script do when called and /usr/bin/install-info is absent? Packages currently call install-info from their maintainer scripts unconditionally, because it's provided by an Essential package. Triggers will replace such maintainer script calls, Not instantaneously! This needs to include a sane transition plan. Don't worry, we'll use triggers is not. IIRC the remaining install-info script is to provide support until all the packages using maintainer scripts calls migrate to using triggers for their info documents. Which means install-info must be reliably present on the system until that transition is finished. Which means dpkg needs to Pre-Depend on install-info. -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install-info transition, review time
On Thu, 26 Mar 2009 00:34:23 -0700 Steve Langasek vor...@debian.org wrote: On Thu, Mar 26, 2009 at 07:21:15AM +, Neil Williams wrote: Also, is the new dpkg going to Pre-Depend: on this new install-info package? If not, what does this /usr/sbin/install-info wrapper script do when called and /usr/bin/install-info is absent? Packages currently call install-info from their maintainer scripts unconditionally, because it's provided by an Essential package. Triggers will replace such maintainer script calls, Not instantaneously! This needs to include a sane transition plan. Don't worry, we'll use triggers is not. Sorry, didn't mean to infer that the change from maintainer scripts to triggers was to be instantaneous across all affected packages, just trying to give some context for the reasons behind the change. IIRC, the /usr/sbin/install-info wrapper was to do nothing (except maybe a warning) if /usr/bin/install-info was not present as the work should be being done by the info package. Some info documents need to be fixed to work with GNU install info to allow the current workload of the dpkg install-info to be offloaded to a later stage when ginstall-info (the GNU version) exists and processes whatever files it finds in the appropriate location. i.e. the dpkg install-info is currently doing more than it needs to do and would be restricted to simply doing what the package maintainer would need to do for trigger support - move the files into the relevant location for ginstall-info to process later. IIRC the remaining install-info script is to provide support until all the packages using maintainer scripts calls migrate to using triggers for their info documents. Which means install-info must be reliably present on the system until that transition is finished. Which means dpkg needs to Pre-Depend on install-info. My expectation was that dpkg would provide a script to allow existing maintainer scripts to complete without error but not necessarily action the info document indexing at that time - simply moving files around. Once the info browser is installed, it would build the database it needs. I may be wrong but IIRC, once the info documents are fixed to be compatible with ginstall-info, the dpkg script actually called by the current maintainer scripts doesn't actually need to do anything other than move files to where they should be placed (a role to be taken on by the packages themselves as trigger support is implemented in each one) and then allow the info browser package to deal with generating the metadata that is currently done at a much earlier stage. There would then be no need to have dpkg pre-depend on install-info (just as it does not pre-depend on man-db). I hope I've got that right, Raphael? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpybU6JTDlwU.pgp Description: PGP signature
Re: Install-info transition, review time
On Thu, 26 Mar 2009, Steve Langasek wrote: I don't like the sound of this. Why is it necessary to provide /usr/sbin/install-info? I assume this is out of concern that some packages will be calling install-info with an explicit path, but that's been contrary to Policy for years (Programs called from maintainer scripts should not normally have a path prepended to them, Policy 6.1) and I don't see any evidence looking at my local systems that install-info is being used incorrectly. http://lintian.debian.org/tags/command-with-path-in-maintainer-script.html Look for /usr/sbin/install-info. There aren't many but there are some. I don't think there should be an extra install-info in the path without a clearer rationale. We could drop the script entirely but IMO it's better to keep it until the transition is complete. install-info could be assumed to be on the PATH due to its inclusion in the essential set. We want to remove it from there, so I prefer to keep an informative wrapper that doesn't fail in the transition period. How long should we keep it ? I'm not sure. At the very least as long as the transition is on-going in sid, maybe until the squeeze release. Also, is the new dpkg going to Pre-Depend: on this new install-info package? No. The purpose of install-info is to update the dir file. The dir file is used by the info-browsers to show an index of all info files. dpkg is going to Breaks: on old versions of all info-browsers that do not depend on install-info. Thus the dpkg upgrade will force the upgrade of the info-browsers at the same time (and hence assure that the install-info package is installed when needed). We avoid a Pre-Depends immediately and we make it immediately easier for people that creates systems that can live without install-info. (Yes in case you haven't noticed, Emdebian is interested in that) If not, what does this /usr/sbin/install-info wrapper script do when called and /usr/bin/install-info is absent? Packages currently call install-info from their maintainer scripts unconditionally, because it's provided by an Essential package. It displays a warning that packages have to be updated to not call install-info from their maintainer scripts. If it's not called from a maintainer scripts, it displays a warning saying that it does nothing and that the install-info package provides the functionality. Please review and raise any suggestions if you have any. There has been some extensive discussion on -dpkg already that you can read to understand the choices made: http://lists.debian.org/debian-dpkg/2009/03/msg00019.html Given that install-info is codified in Policy, I think this plan needs to be vetted via the policy process and include specific changes to the language in Policy, prior to moving forward on implementation. What do policy editors think ? Is that a case where we should update policy first or is that a case where the policy should simply document current practice/implementation ? I don't mind, we can take some time to draft this but I would rather appreciate if someone stepped in to take care of this part of the work. On Thu, 26 Mar 2009, Steve Langasek wrote: On Thu, Mar 26, 2009 at 07:21:15AM +, Neil Williams wrote: Also, is the new dpkg going to Pre-Depend: on this new install-info package? If not, what does this /usr/sbin/install-info wrapper script do when called and /usr/bin/install-info is absent? Packages currently call install-info from their maintainer scripts unconditionally, because it's provided by an Essential package. Triggers will replace such maintainer script calls, Not instantaneously! This needs to include a sane transition plan. Don't worry, we'll use triggers is not. Almost instantaneously thanks to the Breaks, the worst part of the transition is the beginning where we have the old dpkg / install-info together with the new install-info package. The old install-info might update the dir file (due to postinst calls to install-info) and the change will be lost when the trigger regenerates the dir file from scratch. Not a big deal IMO. IIRC the remaining install-info script is to provide support until all the packages using maintainer scripts calls migrate to using triggers for their info documents. Which means install-info must be reliably present on the system until that transition is finished. Which means dpkg needs to Pre-Depend on install-info. Or keep /usr/sbin/install-info as a wrapper (that doesn't fail if the system doesn't have any info-browser). Which is the choice we made. I don't think it's unreasonable. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Install-info transition, review time
Hello, the dpkg team and the texinfo maintainer have laid out a plan to get rid of dpkg /usr/sbin/install-info and start relying on GNU's install-info when needed. This will involve some work to transition properly. We have described our plan here: http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo Please review and raise any suggestions if you have any. There has been some extensive discussion on -dpkg already that you can read to understand the choices made: http://lists.debian.org/debian-dpkg/2009/03/msg00019.html Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
