Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
On Fri, 13 Mar 2009 13:54:38 +0100 Simon Richter wrote: *sigh* - time to call a halt and face the problems head on. So, let me spell things out, plain and simple. > > >, since > > > they have entirely different objectives > > > Not entirely different - the objective for the packaging tools is > > actually the same, to have packages install cleanly without changes on > > systems with a different architecture triplet. > > I'm not sure this can be achieved at all, as we still need a root > filesystem that isn't prefixed with the architecture triplet. That isn't acceptable - the current situation is untenable and a replacement must be found. The only current candidate is multiarch and what looks like an inevitable handler within dpkg to move certain paths around where necessary. This handler would later use DpkgClass support to intelligently handle files within packages that dpkg-cross currently considers "interesting" whilst dropping other files where there is no chance of executing them (typically, ordinary binaries). dpkg-cross has no future, neither does apt-cross. There is no possible mechanism for retaining the current methodology - it is fundamentally broken (because it tries to work around standard tools instead of moving with them) and it has shown that it cannot support the original aim, to allow sufficient portions of Debian to be cross-built sanely. I've worked with the code (almost exclusively) for two years now, I think it should be clear that I have no desire to do so for another two, let alone another ten. apt-cross, in particular, is already moribund. The only reason this is an issue at all is that it has taken 10 years to get to the point where we finally need to drop dpkg-cross and therefore we've got used to something that was never truly capable of being supported for the long term. That is not sufficient reason to retain it - it is a clear and adequate reason to remove it. I have no desire to release dpkg-cross or apt-cross with Squeeze. Their time has come and gone. I'm grateful for what the tools were able to support during the time that they were useful but *that time has passed* and both are now holding back development of stable, usable, friendly and reliable cross-building methods in Debian and Emdebian. Right now, there is no greater single barrier to Emdebian Crush than apt-cross and it's reliance on dpkg-cross instead of dpkg. If we want Emdebian Crush 2.0, we need to drop dpkg-cross. That is the reality - unless we drop dpkg-cross and apt-cross before the toolchain freeze for Squeeze, Emdebian Crush 2.0 might not release at all. We would face exactly the same issues in Squeeze+1 without the opportunity that currently exists to get our changes into dpkg, making it hard to see how Crush could recover. > The other issue is that generally, the 32/64 bit distinction does not > necessarily mean that we use a different triplet. i386/amd64 does, at least > in Debian, but that is optional as well and could be changed in the gcc > package, which would give us a situation where only clearly incompatible > arches need to be installed into a triplet directory. If things change, we continue to adapt. Never been a problem for us in the past. However, if we ignore the opportunity to get our needs addressed within the core Debian infrastructure, we only make things harder for the future. > > >, and there is generally no need to > > > install anything but libraries and headers into /usr/ -- so I > > > don't think there is a pressing need to replicate a filesystem hierarchy > > > standard below a triplet directory. > > > True, however, that is not a sufficient reason to not > > move /usr/ to /usr/lib/ and /usr/include/ > > if it means getting such support into the core Debian packaging tools. That is about the size of it, yes. > Indeed, however this makes building stuff without the packaging tools a lot > harder I disagree - it makes it about as hard as it is already. What's different is that the mulitarch method is untested and unfamiliar but that is hardly surprising. OK, so multiarch may need more changes in the future to make things easier but multiarch is the only viable option and we cannot afford to block ourselves into a corner by ignoring it or refusing to make it work for us. > -- for example I need to patch gcc to recognize these paths if I > build gcc by hand. Someone had to patch gcc originally to make that support available, the same needs to happen here. Debian makes lots of changes to gcc for Debian needs, I really don't see that this can be used as an excuse to block the original objective - getting cross-building support into the core Debian packaging tools. The price of that support is multiarch. > It might be a lot easier to have the packaging tools > handle the "current" layout than to patch all the software that assumes > that software is generally installed into "include" and "lib" dirs under a > common prefix (such as most GNU software that uses th
Re: Transition from dpkg to GNU install-info
Hi all, I have no checked all packages in the current sid archive for info files, extracted all of them and checked with (an updated) update-info-dir. There are about 50 packages where a proper dir entry is missing. GNU install-info warns: warning: no info dir entry in ... What should we do with these packages? Should we first file bugs against all those packages? Best wishes Norbert --- Dr. Norbert Preining Vienna University of Technology Debian Developer Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- PELUTHO (n.) A South American ball game. The balls are whacked against a brick wall with a stout wooden bat until the prisoner confesses. --- Douglas Adams, The Meaning of Liff usr/share/info/python2.5-lib.info.gzcontrib/doc/python2.5-doc usr/share/info/ocaml.info.gznon-free/doc/ocaml-doc usr/share/info/xcdesign.info.gz doc/xconq-doc usr/share/info/ocp.info.gz sound/opencubicplayer usr/share/info/mathgl.info.gz doc/mathgl-doc usr/share/info/python2.4-mac.info.gzcontrib/doc/python2.4-doc usr/share/info/xemacs21/emodules.info.gzeditors/xemacs21-support usr/share/info/bcron.info.gzadmin/bcron usr/share/info/gmediaserver.info.gz net/gmediaserver usr/share/info/opt.info.gz devel/opt usr/share/info/gnu-crypto.info.gz libs/libgnucrypto-java usr/share/info/hacking.info.gz doc/xconq-doc usr/share/info/mime-en.info.gz mail/flim usr/share/info/source-highlight.info.gz devel/source-highlight usr/share/info/smbc.info.gz net/smbc usr/share/info/python2.5-ref.info.gzcontrib/doc/python2.5-doc usr/share/info/mime-ui-en.info.gz mail/semi usr/share/info/sdic.info.gz contrib/text/sdic usr/share/info/mime-ui-ja.info.gz mail/semi usr/share/info/oleo.info.gz math/oleo usr/share/info/cloog.info.gzlibdevel/libcloog-ppl-dev usr/share/info/gtkdialog.info.gzinterpreters/gtkdialog usr/share/info/RealTimeBattle.info.gz games/realtimebattle-common usr/share/info/python2.5-ext.info.gzcontrib/doc/python2.5-doc usr/share/info/edb.info.gz misc/edb usr/share/info/robotfindskitten.info.gz games/robotfindskitten usr/share/info/python2.4-api.info.gzcontrib/doc/python2.4-doc usr/share/info/muddleftpd.info.gz net/muddleftpd usr/share/info/ladcca-manual.info.gzsound/ladcca-bin usr/share/info/python2.5-mac.info.gzcontrib/doc/python2.5-doc usr/share/info/tua.info.gz comm/tua usr/share/info/jargon.info.gz doc/jargon usr/share/info/quelcom.info.gz sound/quelcom usr/share/info/python2.5-tut.info.gzcontrib/doc/python2.5-doc usr/share/info/python2.4-ext.info.gzcontrib/doc/python2.4-doc usr/share/info/python2.4-ref.info.gzcontrib/doc/python2.4-doc usr/share/info/netmask.info.gz net/netmask usr/share/info/python2.4-lib.info.gzcontrib/doc/python2.4-doc usr/share/info/xmorph.info.gz graphics/xmorph usr/share/info/python2.5-dist.info.gz contrib/doc/python2.5-doc usr/share/info/tora.info.gz misc/tora usr/share/info/ispell.info.gz text/ispell usr/share/info/barcode.info.gz graphics/barcode usr/share/info/latex2rtf.info.gzdoc/latex2rtf-doc usr/share/info/libvformat.info.gz libdevel/libvformat1-dev usr/share/info/python2.4-tut.info.gzcontrib/doc/python2.4-doc usr/share/info/accounting.info.gz admin/acct usr/share/info/python2.4-dist.info.gz contrib/doc/python2.4-doc usr/share/info/diff.info.gz doc/diff-doc usr/share/info/VFlib-36.info.gz doc/vflib3-doc usr/share/info/mime-ja.info.gz mail/flim usr/share/info/jed.info.gz editors/jed-common usr/share/info/xconq.info.gzdoc/xconq-doc usr/share/info/snmpkit.info.gz libdevel/libsnmpkit-dev usr/share/info/python2.5-api.info.gzcontrib/doc/python2.5-doc usr/share/info/menu.info.gz admin/menu
Re: Transition from dpkg to GNU install-info
Hi, On Sun, 15 Mar 2009, Norbert Preining wrote: > I have no checked all packages in the current sid archive for info > files, extracted all of them and checked with (an updated) > update-info-dir. > > There are about 50 packages where a proper dir entry is missing. GNU > install-info warns: > warning: no info dir entry in ... > What should we do with these packages? Should we first file bugs against > all those packages? Sure, they have to be fixed. But it should not block the transition IMO. They can be fixed at any point in time. The documentation is usable, it simply doesn't appear on the main index, is that right ? Please use a usertag if you file bugs so that we can track them. 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-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition from dpkg to GNU install-info
On Fr, 13 Mär 2009, Raphael Hertzog wrote: > I guess so. Asking for review/test on -devel is certainly a good idea at > this point. I have prepared a document/email. Can one of you take a look at that and extend/clarify/whatever it? For testing I always put up the lastest experimental source at the usual place, is there a way to get dpkg with your patch? Best wishes Norbert --- Dr. Norbert Preining Vienna University of Technology Debian Developer Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `If there's anything more important than my ego around, I want it caught and shot now.' --- Zaphod. --- Douglas Adams, The Hitchhikers Guide to the Galaxy Announce and RFC: Replace dpkg install-info with GNU install-info The dpkg and TeX Team will replace dpkg install-info with GNU install-info. For that we have prepared a transition plan, testing packages, and now we would like to ask for review and comments before we upload to unstable. The general layout is as follows: - dpkg ships a new /usr/sbin/install-info that will warn the user if called with an absolute path, and then as well as in the normal case call /usr/bin/install-info with the very same arguments. - The source package texinfo builds a new binary package install-info that provides /usr/bin/install-info (a script, see below), and as before /usr/bin/ginstall-info, the real GNU install-info. - The script /usr/bin/install-info will check whether it was called from a maintainer script (by checking for $DPKG_RUNNING_VERSION) and if it is it warns but does not do anything else due to the implementation of triggers. If it is not called from a maintainer script it gives a warning that this is not dpkg install-info any more and calls ginstall-info with the very same arguments. - The install-info package shows interest in the file/dir trigger in /usr/share/info/. If any file is dropped there the triggered action of the package is called which is calling update-info-dir - The script /usr/sbin/update-info-dir is new and will regenerate the dir file from the set of all installed info documents by calling ginstall-info on each of them This last step currently breaks the inclusion of about 50 info documents from all about 580 currently in sid. These package will still work but will not appear in the global dir index (so "info jargon" will work, but it will not be found in the dir file). We will file bugs against these packages to fix the texi input file to get a proper info-dir entry. Time line: - inform the maintainers of info-browsers about the fact that they should now depend on install-info - upload texinfo with the install-info to sid - upload a new dpkg with breaks against the various info-browsers - file bugs against all the info shipping packages with problematic info files Open questions: - the file trigger should be mentioned in the policy - review of update-info-dir script Thanks for any comments or suggestions Norbert Preining Links: - tansition document from an earlier transition plan http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo - svn branch of texinfo package svn://svn.debian.org/debian-tex/texinfo/branches/split-ii - thread on the discussion http://lists.debian.org/debian-dpkg/2009/03/msg00019.html
Re: Transition from dpkg to GNU install-info
Hello Norbert, Sorry for not answering before and thanks a lot for your work on this topic. On Sun, Mar 15, 2009 at 06:49:53PM +0100, Norbert Preining wrote: > > Time line: > - inform the maintainers of info-browsers about the fact that they > should now depend on install-info > - upload texinfo with the install-info to sid > - upload a new dpkg with breaks against the various info-browsers This should probably be: - upload a new dpkg with breaks against the version of upload info-browsers which did not depend on install-info > - file bugs against all the info shipping packages with problematic info > files Maybe recommend that install-info should be called without options but the info files themselves should be updated. And --section shall be avoided (this is IIRC the most problematic option) > Open questions: > - the file trigger should be mentioned in the policy > - review of update-info-dir script I remember there could be some issue with emacs info files (because they are installed in sub-directories?) I will try to review update-info-dir next week. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition from dpkg to GNU install-info
Hi! On Fri, 2009-03-13 at 09:18:03 +0100, Raphael Hertzog wrote: > That looks almost right. I hope Guillem can confirm that it's ok for him > as well. > On Fri, 13 Mar 2009, Norbert Preining wrote: > > We will have 3 different install-info: > > > > 1) /usr/sbin/install-info from dpkg > > this one will do: > > . if called with absolute path, warn the user to use > > /usr/bin/install-info Actually, if called with an absolute path, the warning should ask the caller to not use such absolute path (maybe as a side note, explain the rationale, because it's generally wrong, and in this case because it will stop working if using /usr/sbin/). > > . if called and there is no /usr/bin/install-info give a big fat > > warning and die. Or? > > Dying is not really an option. It might be legitimate that > /usr/bin/install-info is not here: because no info reader is installed. Right. Also I guess when warning we want to distinguish here the case a maintainer script is calling us, which then we want to explain that they should stop doing so, as this is handled by triggers now. And the case a user is calling us which we'd recommend them installing at least the install-info package and maybe an info-browser. Otherwise as there's no /usr/bin/install-info we'll not be able to give accurate info. > The Breaks: added to dpkg ensures that info browsers have the right > dependency on install-info. That's enough, there's no reason to die. Right. > > . Otherwise call /usr/bin/install-info "$@" > > 2) /usr/bin/install-info from install-info > > this one will do: > > . if called from within a maintainer script (! -z "$DPKG_RUNNING_VERSION") > > then simply warn that the package should be updated and do nothing Same as the new dpkg's install-info. > > . otherwise call simply ginstall-info "$@" (and maybe warn?) > Note: if we really wanted, we could avoid that intermediary wrapper and > have it in dpkg but that would mean that the "install-info" interface is > deprecated and that user are expected to use ginstall-info in the long > term. Well, I don't see why that'd be the case. The install-info package can always reclaim the correct path name in the future once we drop the wrapper from dpkg. Also no one should be using absolute paths anyway, and maintainer scripts are not expected to be calling it once the transition is started either. Remember install-info will just disappear at some point from essential, so anyone unconditionally calling it would be as broken. And we are not going to be advertising to use ginstall-info directly. I still think two different wrappers is a bit overkill. Both will need to implement mostly the same behaviour, as dpkg's install-info cannot assume that the install-info package is installed. > If the official upstream name is install-info, then we should rather keep > that intermediary wrapper. It is, but for example automake generated Makefiles have been ignoring Debian's install-info for long time, and will not fail if it's not present either, and it is also mostly only useful if you are installing to a system directory (which implies a root invokation). Anyway I think I'd prefer only one install-info in /usr/sbin/, but would not mind the other one in /usr/bin/. In the latter case both should be mostly identical IMO, either hardlinks in dpkg, or the same source code duped in both packages (dpkg and install-info). regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition from dpkg to GNU install-info
On Mon, 2009-03-16 at 01:45:22 +0100, Nicolas François wrote: > On Sun, Mar 15, 2009 at 06:49:53PM +0100, Norbert Preining wrote: > > Time line: > > - inform the maintainers of info-browsers about the fact that they > > should now depend on install-info > > - upload texinfo with the install-info to sid > > - upload a new dpkg with breaks against the various info-browsers > > This should probably be: > - upload a new dpkg with breaks against the version of upload > info-browsers which did not depend on install-info Yeah. > > - file bugs against all the info shipping packages with problematic info > > files > > Maybe recommend that install-info should be called without options but the > info files themselves should be updated. > And --section shall be avoided (this is IIRC the most problematic option) Just to clarify this in case it causes confusion, no maintainer script should be calling install-info anymore. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
