Re: Getting dh_install to do what we need

2011-12-12 Thread Gergely Nagy
Nicolas Boulenguez writes: > 3/ The way debhelper splits its work in small tools does not always > fit the separation of human concerns. For example, the following is > IMHO more readable that generating/executing a single debian/*.install > file in which each line deals with a different library.

Re: Getting dh_install to do what we need

2011-12-12 Thread Gergely Nagy
Goswin von Brederlow writes: >> So, in this case, the difference is negligible, both can be trivially >> understood. >> >> However, it gives more flexibility to the maintainer, to do more complex >> stuff, if so needs be. But, that won't be the common case. Why? Because >> there's no point in ove

authbind (LD_PRELOAD) and multiarch

2011-12-12 Thread Ian Jackson
I'm maintainer and upstream for authbind, which is a set-id helper to permit and control the binding of low ports by unprivileged programs, with an LD_PRELOAD wrapper so it can be used by naive callers which just expect to call bind. I would like some advice about how to do multiarch support for i

Re: authbind (LD_PRELOAD) and multiarch

2011-12-12 Thread Raphael Hertzog
On Mon, 12 Dec 2011, Ian Jackson wrote: > * I will need to arrange for the same LD_PRELOAD setting to load the >correct libauthbind for each arch. So I guess I do >LD_PRELOAD=libauthbind.so.1 rather than supplying an absolute path, >and trust ld.so to get the right one out of /usr/lib

Re: authbind (LD_PRELOAD) and multiarch

2011-12-12 Thread Raphael Hertzog
On Mon, 12 Dec 2011, Raphael Hertzog wrote: > > To best avoid transitional problems I guess piece 2 should go into > > "authbind" (Multi-arch: same; Depends: authbind-support) and pieces 1 > > and 3 would in "authbind-support" (Multi-arch: foreign; no > > dependency). But I'm not sure. > > Yes.

Re: authbind (LD_PRELOAD) and multiarch [and 1 more messages]

2011-12-12 Thread Ian Jackson
Raphael Hertzog writes ("Re: authbind (LD_PRELOAD) and multiarch"): > On Mon, 12 Dec 2011, Ian Jackson wrote: > > * I will need to arrange for the same LD_PRELOAD setting to load the > >correct libauthbind for each arch. So I guess I do > >LD_PRELOAD=libauthbind.so.1 rather than supplying

Re: Getting dh_install to do what we need

2011-12-12 Thread Goswin von Brederlow
Gergely Nagy writes: > Goswin von Brederlow writes: > >>> So, in this case, the difference is negligible, both can be trivially >>> understood. >>> >>> However, it gives more flexibility to the maintainer, to do more complex >>> stuff, if so needs be. But, that won't be the common case. Why? Bec

Re: Red Hat is moving from / to /usr/

2011-12-12 Thread Goswin von Brederlow
Reinhard Tartler writes: > On Mo, Dez 12, 2011 at 05:36:41 (CET), Karl Goetz wrote: > > [...] > >>> The initramfs on the other hand is made to fit. So if /usr isn't on a >>> networking filesystem (NFS) then you won't get networking stuff in the >>> initramfs. No raid then mdadm isn't included. No

Bug#651858: ITP: etm -- event and task manager using simple text files

2011-12-12 Thread Eike Nicklas
Package: wnpp Severity: wishlist Owner: Eike Nicklas -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: etm Version : 883 Upstream Author : Daniel Graham * URL : http://www.duke.edu/~dgraham/ETM/ * License : GPL Programming Lang: Python Descrip

RFA/O: jed and related packages

2011-12-12 Thread Steve McIntyre
[ NB: CCing the last seen maintainers and Wookey, who expressed some interest IRL... ] Hi folks, I've been looking through build failures lately, triggered mainly by working on the armhf bootstrap. While there are a small number of real armhf-related bugs, the vast majority that we're seeing ar

Re: Getting dh_install to do what we need

2011-12-12 Thread Gergely Nagy
Goswin von Brederlow writes: >>> At a glance what does this do? >> [...] >> >> It triggers my "slap the maintainer silly" button. Other than that, it's >> dead simple: copy a file from one place to the other (with possibly >> renaming the file), with the file list following the while loop. > > No

Re: Getting dh_install to do what we need

2011-12-12 Thread Joey Hess
Gergely Nagy wrote: > At the moment, I have something that works like this: > > , > | #! /usr/bin/dh-exec-install > | # The next one will simply echo it back to dh_install > | source-file /dest-dir/ > | > | # This one will copy the file itself, following similar heuristics as > | # dh_install:

Re: Red Hat is moving from / to /usr/

2011-12-12 Thread Karl Goetz
On Mon, 12 Dec 2011 08:11:55 +0100 Reinhard Tartler wrote: > On Mo, Dez 12, 2011 at 05:36:41 (CET), Karl Goetz wrote: > > [...] > > >> The initramfs on the other hand is made to fit. So if /usr isn't > >> on a networking filesystem (NFS) then you won't get networking > >> stuff in the initramfs

Re: options: was Red Hat is moving from / to /usr/

2011-12-12 Thread Gordon Haverland
I'm a UN*X dinosaur. I started using UN*X in 1984. I don't like this idea of folding /bin, /sbin, /usr/sbin into /usr/bin. I think the reasons to segregate /bin, /sbin, /usr/bin, /usr/sbin and anything in /usr/local/* still exist today. I want more segregation, not less. Actually, I've wante

Re: options: was Red Hat is moving from / to /usr/

2011-12-12 Thread Ben Hutchings
On Mon, 2011-12-12 at 18:55 -0700, Gordon Haverland wrote: > I'm a UN*X dinosaur. I started using UN*X in 1984. > > I don't like this idea of folding /bin, /sbin, /usr/sbin into > /usr/bin. > > I think the reasons to segregate /bin, /sbin, /usr/bin, /usr/sbin > and anything in /usr/local/* sti