Re: Transition from dpkg to GNU install-info
Hi, On Fri, 13 Mar 2009, Norbert Preining wrote: > On Do, 12 Mär 2009, Raphael Hertzog wrote: > > Relying on the order inside PATH is too fragile IMO. If you want to have > > the binary as install-info directly, you'll have to wait until > > install-info is not used any more by debian packages, i.e. for squeeze+1. > > Ok, let me sum up the approach as I understood it: That looks almost right. I hope Guillem can confirm that it's ok for him as well. > 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 > . 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. 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. > . 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 > . 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. If the official upstream name is install-info, then we should rather keep that intermediary wrapper. > Ok, I have uploaded 4.13a.dfsg.1-2~exp04 to the usual place at > http://people.debian.org/~preining/TeX/i-i/ which implements that. What > is missing is the dpkg part shipping a different /usr/sbin/i-i. > > So what do we do next? I can try to prepare a dpkg patch this WE so that we can test. But we have to handle the info browsers first before we can upload dpkg. Which in turn means that the new install info must be available in sid. 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: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Hi, On Thu, Mar 12, 2009 at 07:54:49PM +0100, Hector Oron wrote: > > 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. > That is what GNU people expect when building cross tools, they use a > switch called sysroot for it and it is the recommended way to build such > cross tools. As far as I've understood, --with-sysroot gives the path to the target OS installation so the build can run "fixincludes" and add it to the search paths; since it should work with a largely unmodified snapshot of the target OS, they are pretty tolerant with the directory layout there. I don't believe that is meant as an endorsement of a particular layout, and it should work fine with --with-sysroot=/usr/ even with the current layout. Simon -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Hello Simon, > As far as I've understood, --with-sysroot gives the path to the target OS > installation so the build can run "fixincludes" and add it to the search > paths; since it should work with a largely unmodified snapshot of the > target OS, they are pretty tolerant with the directory layout there. I > don't believe that is meant as an endorsement of a particular layout, and > it should work fine with --with-sysroot=/usr/ even with the > current layout. Right, but it expects include/ to be under usr/include/ as FHS wants. In practice, I did a build for gcc-4.3 and here you have some of the results: Binutils 2.18 configure: ~ ../configure --host=x86_64-linux-gnu \ --build=x86_64-linux-gnu --target=s390-linux-gnu --prefix=/usr \ --enable-targets=s390x-linux-gnu --with-sysroot=/usr/s390-linux-gnu/ GCC-4.3 configure: ~~ ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl='file:///usr/share/doc/gcc-4.3/README.Bugs' --enable-languages=c,c++,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/s390-linux-gnu/include/c++/4.3.2 --program-suffix=-4.3 --with-sysroot=/usr/s390-linux-gnu/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-long-double-128 --enable-checking=release --program-prefix=s390-linux-gnu- --includedir=/usr/s390-linux-gnu/include --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=s390-linux-gnu Output error: ~ /home/zumbi/buildcross/trunk/s390/gcc-4.3-4.3.2/build/./gcc/xgcc -B/home/zumbi/buildcross/trunk/s390/gcc-4.3-4.3.2/build/./gcc/ -B/usr/s390-linux-gnu/bin/ -B/usr/s390-linux-gnu/lib/ -isystem /usr/s390-linux-gnu/include -isystem /usr/s390-linux-gnu/sys-include -O2 -O2 -g -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o 64/libgcc_s.so.1.tmp -O2 -g -g -O2 -m64 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o -lc && rm -f 64/libgcc_s.so && if [ -f 64/libgcc_s.so.1 ]; then mv -f 64/libgcc_s.so.1 64/libgcc_s.so.1.backup; else true; fi && mv 64/libgcc_s.so.1.tmp 64/libgcc_s.so.1 && ln -s libgcc_s.so.1 64/libgcc_s.so /usr/s390-linux-gnu/bin/ld: skipping incompatible /usr/s390-linux-gnu/lib/libc.so when searching for -lc /usr/s390-linux-gnu/bin/ld: skipping incompatible /usr/s390-linux-gnu/lib/libc.a when searching for -lc /usr/s390-linux-gnu/bin/ld: skipping incompatible /usr/s390-linux-gnu/bin/../../lib/libc.so when searching for -lc /usr/s390-linux-gnu/bin/ld: skipping incompatible /usr/s390-linux-gnu/bin/../../lib/libc.a when searching for -lc /usr/s390-linux-gnu/bin/ld: s390:31-bit architecture of input file `/usr/s390-linux-gnu/lib/crti.o' is incompatible with s390:64-bit output /usr/s390-linux-gnu/bin/ld: s390:31-bit architecture of input file `/usr/s390-linux-gnu/lib/crtn.o' is incompatible with s390:64-bit output collect2: ld returned 1 exit status -- Héctor Orón -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Atique Mirza ( FILMEX STUDIOS)
Dear Sir, Filmex is offering Catalogue Desingin, Photography, Broucher Designing Domain Registration & Printing Service for more information contact at: FILMEX STUDIOS Azam Block, Model Town, Sialkot 51310 Pakistan. Telephone: +92 52 3259477 - 3559480 Mobile: +92 300 871 4800 Email: fil...@gmail.com Url: www.filmex.pk -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Hi, > >, 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. 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. > >, 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. Indeed, however this makes building stuff without the packaging tools a lot harder -- for example I need to patch gcc to recognize these paths if I build gcc by hand. 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 the autoconf macros to find installed software). Simon -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Hello, >>> , 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. > > Indeed, however this makes building stuff without the packaging tools a lot > harder -- for example I need to patch gcc to recognize these paths if I > build gcc by hand. 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 the autoconf macros to > find installed software). That's totally right and that is my point, I really think multiarch is not well designed to fit into cross compiling. They (dpkg-core) might want us to do extra work which will break our stuff. And as from the point of view of multiarch we probably have a nice, simple and working solution right now, without even notice it. The only reason I found against our approach is: " Why not prefix/arch-os/lib/ (and include/)? It would pollute the prefix directory. Can you imagine adding one entry for each target to the root and /usr directories? Better that they go under the prefix/lib/ (and include/) directories which already contain many files. " Which in practice it is not so bad to do all the extra work that multiarch needs to get done. Please correct me if I am wrong -- 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 all, On Fr, 13 Mär 2009, Raphael Hertzog wrote: > That looks almost right. I hope Guillem can confirm that it's ok for him > as well. That would be great. > > 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 > > . 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. > > 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. Ok, who is going to write the dpkg install-info wrapper? > 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. No that we don't want at all!! > If the official upstream name is install-info, then we should rather keep > that intermediary wrapper. Right. We keep the intermediate wrapper, and after squeeze or so we drop all of the wrappers and ship only install-info as GNU. > I can try to prepare a dpkg patch this WE so that we can test. > > But we have to handle the info browsers first before we can upload dpkg. > Which in turn means that the new install info must be available in sid. Why? What would change? info-browsers (see below) should depend on install-info, but if they don't well, then we file a bug to fix that. But we should have install-info first in sid. Anyway, does that mean with the ok of more people here that after testing dpkg (hopefully after the weekend with your patch) I should upload to sid? Apropos info browsers, that would be: info (me) pinfo tkinfo plus several others that ship as "info-browser" emacs (why does each and every emacs package provide info-browser) (x)jed (why please does jed-extra provide info-browser?) konqueror xemacs* (same) 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 --- SWANAGE (pl.n.) Swanage is the series of diversionary tactics used when trying to cover up the existence of a glossop (q.v.) and may include (a) uttering a high-pitched laugh and pointing out of the window (NB. this doesn't work more that twice); (b) sneezing as loudly as possible and wiping the glossop off the table in the same movement as whipping out your handkerchief; (c) saying 'Christ! I seen to have dropped some shit on your table' (very unwise); (d) saying 'Christ, who did that?' (better) (e) pressing your elbow on the glossop itself and working your arms slowly to the edge of the table; (f) leaving the glossop where it is but moving a plate over it and putting up with sitting at an uncomfortable angle the rest of the meal; or, if the glossop is in too exposed a position, (g) leaving it there unremarked except for the occasional humorous glance. --- Douglas Adams, The Meaning of Liff -- 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 Fri, 13 Mar 2009, Norbert Preining wrote:
> > 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.
>
> Ok, who is going to write the dpkg install-info wrapper?
I just wrote it. I had to do it in C otherwise I couldn't do the check
on how it's called.
Patch attached and test package at:
http://people.debian.org/~hertzog/packages/dpkg_1.15.1~testii_i386.changes
Branch pu/install-info at:
http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/install-info
git://git.debian.org/users/hertzog/dpkg.git
> > If the official upstream name is install-info, then we should rather keep
> > that intermediary wrapper.
>
> Right. We keep the intermediate wrapper, and after squeeze or so we drop
> all of the wrappers and ship only install-info as GNU.
Yes.
> > But we have to handle the info browsers first before we can upload dpkg.
> > Which in turn means that the new install info must be available in sid.
>
> Why? What would change? info-browsers (see below) should depend on
> install-info, but if they don't well, then we file a bug to fix that.
> But we should have install-info first in sid.
When we upload dpkg to sid, if it contains the Breaks dep,
it will effectively break all info-browsers that have not been updated
yet. It's best to avoid that if possible by doing the dpkg upload after
the info-browsers update.
> Anyway, does that mean with the ok of more people here that after
> testing dpkg (hopefully after the weekend with your patch) I should
> upload to sid?
I guess so. Asking for review/test on -devel is certainly a good idea at
this point.
> Apropos info browsers, that would be:
> info (me)
> pinfo
> tkinfo
> plus several others that ship as "info-browser"
> emacs (why does each and every emacs package provide info-browser)
> (x)jed (why please does jed-extra provide info-browser?)
> konqueror
> xemacs* (same)
That will give a somewhat bloated Breaks line but it's better than
allowing broken combinations.
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/
>From 3c9d26c5d5c21ad41f4cbc6ed772048352628f76 Mon Sep 17 00:00:00 2001
From: Raphael Hertzog
Date: Fri, 13 Mar 2009 15:47:52 +0100
Subject: [PATCH] Replace install-info by a simple wrapper (or no-op command)
In order to properly transition to GNU's install-info, dpkg's install-info
is modified to be a simple wrapper around /usr/bin/install-info. That
wrapper warns when the user explicitely calls /usr/sbin/install-info since
the new install-info is in /usr/bin/.
This wrapper is meant to be removed at some point when all references
to /usr/sbin/install-info have gone (most probably in squeeze+1).
Also remove the manual page since there's nothing to document any more
and add a lintian override until the wrapper is removed.
TODO: Add the breaks on all info browsers.
Reference: http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo
---
debian/dpkg.install |1 -
debian/dpkg.lintian-overrides |2 +
man/Makefile.am |1 -
man/install-info.8| 295 ---
man/po/po4a.cfg |5 -
po/POTFILES.in|1 -
scripts/Makefile.am | 16 +--
scripts/install-info.pl | 524 -
utils/.gitignore |1 +
utils/Makefile.am | 14 +-
utils/install-info.c | 34 +++
11 files changed, 51 insertions(+), 843 deletions(-)
delete mode 100644 man/install-info.8
delete mode 100755 scripts/install-info.pl
create mode 100644 utils/install-info.c
diff --git a/debian/dpkg.install b/debian/dpkg.install
index 8e956cd..599c02f 100644
--- a/debian/dpkg.install
+++ b/debian/dpkg.install
@@ -23,7 +23,6 @@ usr/share/man/{*/*,*}/dpkg-statoverride.8
usr/share/man/{*/*,*}/dpkg-trigger.1
usr/share/man/{*/*,*}/dpkg.cfg.5
usr/share/man/{*/*,*}/dpkg.1
-usr/share/man/{*/*,*}/install-info.8
usr/share/man/{*/*,*}/start-stop-daemon.8
usr/share/man/{*/*,*}/update-alternatives.8
usr/share/perl5/Dpkg.pm
diff --git a/debian/dpkg.lintian-overrides b/debian/dpkg.lintian-overrides
index eb946ed..96d2a70 100644
--- a/debian/dpkg.lintian-overrides
+++ b/debian/dpkg.lintian-overrides
@@ -2,3 +2,5 @@ dpkg: redundant-origin-field
dpkg: redundant-bugs-field
dpkg: arch-dep-package-has-big-usr-share
dpkg: package-contains-empty-directory usr/share/dpkg/origins/
+# On purpose, install-info is only a wrapper that will be removed soon
+dpkg: binary-without-manpage usr/sbin/install-info
diff --git a/man/Makefile.am b/man/Makefile.am
index 2c0403a..a35c706 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -98,7 +98,6 @@ dist_man_MANS = \
dpkg.cfg.5 \
dselect.1 \
dselect.cfg.5 \
- install-info.8 \
start-stop-daemon.8 \
update-alterna
Re: Transition from dpkg to GNU install-info
Hi Raphael,
thanks a lot for the work.
On Fr, 13 Mär 2009, Raphael Hertzog wrote:
> I just wrote it. I had to do it in C otherwise I couldn't do the check
> on how it's called.
Ok, fine.
> > Why? What would change? info-browsers (see below) should depend on
> > install-info, but if they don't well, then we file a bug to fix that.
> > But we should have install-info first in sid.
>
> When we upload dpkg to sid, if it contains the Breaks dep,
Right, I forgot about the Break stuff. Right.
> > testing dpkg (hopefully after the weekend with your patch) I should
> > upload to sid?
>
> I guess so. Asking for review/test on -devel is certainly a good idea at
> this point.
Ok. Do you have an idea how to test *all* packages containing info files
for success when using ginstall-info? I checked the Contents file
$ zgrep usr/share/info/ Contents-amd64.gz | awk '{print$2}' | sort |
uniq | wc -l
424
so 424 packages ... I don't want to download all of them, install them
plus their dependencies ... uaaa.
At least getting all the info files itself would already be fine,
unpacking /usr/share/info dirs from all packages, uaaa.
BTW, I found that some packages install their info files below
/usr/share/info: emacs-21, emacs-22, lilypond, xemacs-21, xnee (not the
package names) but into sub-directories. Uaa.
I guess I have to rewrite the update-info-dir script anyway to make it
more robust ... help much appreciated!
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
---
WARLEGGAN (n. archaic)
One who does not approve of araglins (q.v.)
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Environment variables, debian/rules and dpkg-buildpackage
[ Bcced to -devel and -dpkg, discussion should happen on -policy ] Hello, we have an unfortunate situation where the practice in dpkg-buildpackage and the policy do not match fully. I tried to summarize the problem here: http://wiki.debian.org/Teams/Dpkg/DebianRules I want to resolve this problem. I see two solutions: * either we modify policy to mandate the set of environment variables that dpkg-buildpackage sets * or we roll-back changes to dpkg-buildpackage and design something else that provide the same feature in terms of distribution-wide control of default build options. (I ignore the DEB_VENDOR feature, it can be easily replaced with dpkg-vendor but the build options case is much more tricky to get right) In terms of efforts, the first solution is the easiest. But we aim at the _right_ solution so feel free to design something that makes the second solution viable. Regards, -- 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
