Re: Getting dh_install to do what we need
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.
>
> # foo stuff
> override_dh_install::
> dh_install --package=libfoo$(FOO_SOVERSION)
> lib/libfoo.so.$(FOO_SOVERSION) usr/lib/$(DEB_HOST_MULTIARCH)
> override_dh_link::
> dh_link --package=libfoo-dev
> usr/lib/$(DEB_HOST_MULTIARCH)/libfoo.so.$(FOO_SOVERSION)
> usr/lib/$(DEB_HOST_MULTIARCH)/libfoo.so
> … more foo stuff
>
> # bar stuff
> override_dh_install::
> dh_install --package=libbar$(BAR_SOVERSION)
> lib/libbar.so.$(BAR_SOVERSION) usr/lib/$(DEB_HOST_MULTIARCH)
> … more bar stuff
>
> # At the end
> override_dh_install::
> dh_install --remaining-packages
> override_dh_link::
> dh_link --remaining-packages
> … and so on
We'll have to disagree here, I find the above overrides awkward, and
harder to follow than this:
debian/rules:
,
| export FOO_SOVERSION=1.0
| %:
| dh $@
`
debian/libfoo1.0.install:
,
| #!/usr/bin/dh_subst
| lib/libfoo.so.${FOO_VERSION} usr/lib/${DEB_HOST_MULTIARCH}
`
And so on...
Why do I find it more readable? Because there aren't any
overrides. Overrides are a horrible, horrible way to customize a
build. They don't really follow the make flow one normally
expects.
Going the executable script route, you can get rid of the overrides, and
I honestly fail to see how a she-bang line would make it less
understandable.
Okay, okay, you will have to trust dh_subst to do the right thing. But
you already trust debhelper, and dh_subst will be a *very* lightweight
and dead-simple tool.
> In short, I think that debian/*.install dynamic content should be
> discouraged.
I disagree, and think that dynamic debhelper files should be encouraged
over overrides.
But each to his own, I guess. We all can use whichever method we prefer,
as both work, and none of us is forced to use the other method if we
don't want to.
In the end, both ways work, and no matter how I happen to feel about
overrides, neither them, nor executable scripts should be discouraged.
--
|8]
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874nx65ev1.fsf@algernon.balabit
Re: Getting dh_install to do what we need
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 overcomplicating things. > > Lets hope it stays at the level where you have a shebang (one of few > well known tools) followed by the normal input. That would be relatively > easy to get used to and understand. So you look at the .install file and > then man dh_subst and you are good. That's the idea. Similarly to the normal dh_* tools, where you look at the man page, and you're good. ;) > 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. This also gave me an idea, and since this use-case seems to be common, I'll probably rename my dh_subst thing to debhelper-exec-extras or something similar, and include a little tool that will cover this use-case aswell. >>> On the other hand we do have packages with executable debhelper files >>> that are NOT scripts. Debhelper currently breaks those. The execute >>> scripts feature should use a compat level. And then you would have the >>> situation you described, where you have to check the compat level and >>> every script. >> >> I'd treat executable files that are not scripts as a bug. They most >> probably don't have a shebang line, and that's just wrong. >> >> Breaking buggy packages is not something I'd worry about. Especially if >> the number is fairly low (and I expect it to be so, but feel free to >> correct me with numbers). > > Around 17 sources for 3.0 (quilt) format. So nothing major. Could be > some more for native packages. So, the number is not fairly low, it's so low that it doesn't even matter. :P -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkey3zy1.fsf@algernon.balabit
authbind (LD_PRELOAD) and multiarch
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 it. authbind consists of three pieces: 1. A setuid-root helper executable /usr/lib/authbind/helper. This helper provides a documented API so that callers who know they want to use authbind can fork/exec the helper themselves. The helper is a pure utility: callers do not need to link it into their address space and on a multiarch system any architecture suitable for running set-id binaries is fine. 2. A shared library intended for use with LD_PRELOAD. It provides a replacement implementation of bind(2). Currently this is in /usr/lib/authbind/libauthbind.so.1.0 but there is no particular reason it shouldn't be in /usr/lib (or /usr/lib/) other than the worry that someone might say -lauthbind. The shared library also uses the _init hook to remove itself from LD_PRELOAD after a while; this is controlled by an environment variable which the shared library also mutates in _init. Obviously the shared library needs to be provided for the architecture of the actual target program; however because of the _init machinery, and ld.so error messages, it should ideally be provided for _all_ architectures which the system is capable of executing. 3. A wrapper program which sets LD_PRELOAD and possibly other variables for the benefit of the shared library, and then execs the desired actual program. This program happens to be a C executable but its architecture is unimportant. Currently all three of these are in the same package. This will obviously have to change. I have a couple of points I'd like input on: * 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/. Is that right ? * AFAICT there is no way on a multiarch system to say in my dependencies "I need this package on all architectures supported on this system". I went and looked at testing's fakeroot but I'm not sure I should be using what it does as an example. How should an LD_PRELOAD hack approach this problem ? 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. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20197.58611.758263.939...@chiark.greenend.org.uk
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 an absolute path, >and trust ld.so to get the right one out of /usr/lib/. >Is that right ? I don't know, ld.so(8) does not document this. (But it doesn't look wrong at least) > * AFAICT there is no way on a multiarch system to say in my >dependencies "I need this package on all architectures supported on >this system". I went and looked at testing's fakeroot but I'm not >sure I should be using what it does as an example. How should an >LD_PRELOAD hack approach this problem ? What does fakeroot do? My first idea would be to fail early and provide a useful error message. Find out the arch of the executable, verify if the corresponding preload library is available. If it's not, then fail and instruct the user to install the missing library. But this means that you have done (part of) the work that you were intending to offload to ld.so. > 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. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111212135059.gd29...@rivendell.home.ouaza.com
Re: authbind (LD_PRELOAD) and multiarch
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. Hum, in fact, the split and the Multi-arch fields are okay but I think that the package names and dependencies are somewhat ill-advised. I would call "authbind" (Multi-arch: foreign) the pieces 1/3 because the user really wants to install the wrapper. I would put the preload library in a "libauthbind" package (Multi-arch: same). The wrapper depends on "libauthbind" because it's relatively useless without the preload library (if we want to be picky, it could be useful with a library of another architecture and without the library of the same architecture, but currently you can't depend on "libfoo:any" if libfoo is Multi-Arch: same). I don't see why the library would have to depend on the binaries (but maybe I misunderstood your description of the helper binaries) and in fact we really want to avoid the dependency loop. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111212140648.ge29...@rivendell.home.ouaza.com
Re: authbind (LD_PRELOAD) and multiarch [and 1 more messages]
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 an absolute path,
> >and trust ld.so to get the right one out of /usr/lib/.
> >Is that right ?
>
> I don't know, ld.so(8) does not document this. (But it doesn't look wrong
> at least)
It does seem to work.
> > * AFAICT there is no way on a multiarch system to say in my
> >dependencies "I need this package on all architectures supported on
> >this system". I went and looked at testing's fakeroot but I'm not
> >sure I should be using what it does as an example. How should an
> >LD_PRELOAD hack approach this problem ?
>
> What does fakeroot do? My first idea would be to fail early and provide a
> useful error message.
>
> Find out the arch of the executable, verify if the corresponding preload
> library is available. If it's not, then fail and instruct the user to
> install the missing library.
I'm afraid that the phrase "the executable" is not clearly defined and
may even be meaningless. fakeroot has this problem much worse, but
even with authbind you might do something like
authbind /etc/init.d/food start
Obviously it would be too much to expect the wrapper to figure out
that eventually the program which we really care about is
/usr/sbin/food and determine its architecture.
fakeroot seems to try to provide multiple libraries for some selection
of architectures in a single package. This must make building it
complicated.
Raphael Hertzog writes ("Re: authbind (LD_PRELOAD) and multiarch"):
> The wrapper depends on "libauthbind" because it's relatively useless
> without the preload library (if we want to be picky, it could be useful
> with a library of another architecture and without the library of the
> same architecture, but currently you can't depend on "libfoo:any" if
> libfoo is Multi-Arch: same).
If you are running biarch amd64/i386 then if you install the wrapper,
you want both the i386 and amd64 libraries. Having the wrapper depend
on the library means you get (only) the library of whatever arch
wrapper you happened to install.
The right dependency isn't "any". It's "all". Or really, "some
specific architecture depending on the arch of the target program
which we may not know".
Following this to its logical conclusion suggests leaving the decision
to the user who will install "libauthbind:amd64" or "libauthbind:i386"
or both.
> I don't see why the library would have to depend on the binaries (but
> maybe I misunderstood your description of the helper binaries) and in fact
> we really want to avoid the dependency loop.
The library will not work without the helper. The helper can work
without the library.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20198.3175.881600.523...@chiark.greenend.org.uk
Re: Getting dh_install to do what we need
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? Because >>> there's no point in overcomplicating things. >> >> Lets hope it stays at the level where you have a shebang (one of few >> well known tools) followed by the normal input. That would be relatively >> easy to get used to and understand. So you look at the .install file and >> then man dh_subst and you are good. > > That's the idea. Similarly to the normal dh_* tools, where you look at > the man page, and you're good. ;) > >> 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. Not quite. It implements support for renaming files during dh_install, implementing the following syntax: file path/ file path/new_name The hack it does is to copy the file in the source directory to the new name and then letting dh_install install it to the destination directory. And yes, like this it is a totaly ugly hack. Does it become better as #!/usr/bin/debhelper-exec-rename or something? > This also gave me an idea, and since this use-case seems to be common, > I'll probably rename my dh_subst thing to debhelper-exec-extras or > something similar, and include a little tool that will cover this > use-case aswell. What if I want to do more than one thing? For example rename and do the variable substitution. Should we have something like #! /usr/bin/debhelper-exec-pipe debhelper-exec-subst debhelper-exec-rename which would pipe the input file through debhelper-exec-subst and debhelper-exec-rename both? Does any Debian port have the limit of only one argument for shebangs? On the other hand we do have packages with executable debhelper files that are NOT scripts. Debhelper currently breaks those. The execute scripts feature should use a compat level. And then you would have the situation you described, where you have to check the compat level and every script. >>> >>> I'd treat executable files that are not scripts as a bug. They most >>> probably don't have a shebang line, and that's just wrong. >>> >>> Breaking buggy packages is not something I'd worry about. Especially if >>> the number is fairly low (and I expect it to be so, but feel free to >>> correct me with numbers). >> >> Around 17 sources for 3.0 (quilt) format. So nothing major. Could be >> some more for native packages. > > So, the number is not fairly low, it's so low that it doesn't even > matter. :P Yes. Don't make a big deal out of this. It was just tickling my funny bone. It isn't a showstopper. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wra1hk7k.fsf@frosties.localnet
Re: Red Hat is moving from / to /usr/
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 lvm and the initramfs >>> gets smaller again. And only select modules for one kernel are in >>> there. Huge space saving again. So an initramfs will/can be minimal. >> >> I assume this means it will be impossible to swap the hdd from one >> system to another without rebuilding the initramfs? Seems like a step >> backwards for flexability. > > Trimming the initramfs is an *optional* feature. > > cf. /etc/initramfs-tools/initramfs.conf > > Cheers, > Reinhard If you swap the hdd from one system to another it doesn't suddenly start requiring raid support or need lvm. What can be a problem is suddenly missing the right module for the controler so no disk is found. This is something you already have for /. Including "mount /usr" in the initramfs in no way changes this. And default is, as Reinhard says, to build a big initramfs with lots of modules in there just in case. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjkphjxv.fsf@frosties.localnet
Bug#651858: ITP: etm -- event and task manager using simple text files
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 Description : event and task manager using simple text files etm provides a simple, intuitive format for using plain text files to store data, a command line interface for viewing stored information in a variety of convenient ways, and a GUI for creating and modifying items as well as viewing them. Displayed items can be grouped by date, context, keyword, or project and can be filtered in various ways. A display of busy and free times is also supported, as is a ledger view of time spent that is suitable for client billing. Alarms are supported for events and repetition for both events and tasks in a powerful and flexible manner. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJO5jGoAAoJEIoCp0MX3vpnFygH/3lMl1qRqVqn+AwIcYYtW2vZ Q+g3qYmrSJoLD5KjumIqzk4/x7ZbWrZrqOiBrbRjirdkBVOAQPeVDw9socY2jeAn eXUUlibyvVoN/48H80AGMyTkVIKK8Rf+/QWEtlfDBunQh9A8Hof4taPlbTVdoz9K kQukvAWNI54/LUZt2qN1GKkyCN8JaLSzVERResCLIz0Hze44YCZVOy2iDfwMk5YN PhZyZl/JamXUsGcD+DO0DgKqID4pUqTAD6ON40HNPAgwveJ+9LiJl8UDkoob6kmr JxsGVB8tfR457C+OFc7G0MwK1Mh4bBsKKdhk0Ko4Unvd29pd5/tN5pX1ScVYHbY= =ysMJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111212165405.3588.43098.reportbug@eike-laptop.spacetime
RFA/O: jed and related packages
[ 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 are generic issues in packages that just haven't been built in a while. One obvious group of packages where that's showing up is the set that is/was maintained by the Debian JED Group (source packages listed): jed jed-extra slang-slirp slcfitsio slcurl slexpat slgdbm slgsl slgtk slhist slpvm slsqlite slwildcard slxfig tess tmexpand The build failures wouldn't be too hard to debug and fix in NMUs, but these packages are looking quite unloved at the moment and NMUing a large set could just leave yet more work for future BSPs etc. Given the comparatively low popcon scores here, I'd personally be more inclined to just file a load of RM bugs, but let's see if there are any people around who might be interested in adopting and working on these packages. Shout now; if there's no response I'll start filing those RM bugs in a couple of weeks. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111212175651.gc18...@einval.com
Re: Getting dh_install to do what we need
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.
>
> Not quite. It implements support for renaming files during dh_install,
> implementing the following syntax:
>
> file path/
> file path/new_name
>
> The hack it does is to copy the file in the source directory to the new
> name and then letting dh_install install it to the destination
> directory.
Yeah... I realized my mistake a minute after sending the message, but at
that point, I was already trying to come up with a she-bang tool that
helps with this case.
This, though, is a valid point against executable scripts, unless
they become somewhat standardized.
> And yes, like this it is a totaly ugly hack. Does it become better as
> #!/usr/bin/debhelper-exec-rename or something?
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: it will first try the source file directly, and if it's
| # not found, try the same path under debian/tmp/. The destination is
| # relative to debian/${PACKAGE} (as per dh compat level 7+)
| #
| # Since dh-exec-install does the copying itself, this line is NOT
| # echoed back to dh_install.
| source-file /dest-dir/new-name
`
My implementation copies the file to the desired destination, which may
or may not be a good idea - I'll do some more tests to see which one's
less painful and more safe.
I'm leaning towards copying to the destination with dh-exec-install
directly, as that avoids the possibility of naming conflicts within the
source (however unlikely that may be).
>> This also gave me an idea, and since this use-case seems to be common,
>> I'll probably rename my dh_subst thing to debhelper-exec-extras or
>> something similar, and include a little tool that will cover this
>> use-case aswell.
>
> What if I want to do more than one thing? For example rename and do the
> variable substitution. Should we have something like
>
> #! /usr/bin/debhelper-exec-pipe debhelper-exec-subst debhelper-exec-rename
>
> which would pipe the input file through debhelper-exec-subst and
> debhelper-exec-rename both?
>
> Does any Debian port have the limit of only one argument for shebangs?
Good question!
I thought about this too, and the current idea is a dh-exec tool, that
wraps the rest, and puts them in the appropriate order that makes sense
in 99% of the cases (with the current two tools: this will be
dh-exec-subst | dh-exec-install, so that we get variable expansion
before copy-stuff). This, however, is not completely implemented
yet. I'll fix that in a couple of hours when I near a computer.
And if so need be, this can be later extended with --with-$tool and
--without-$tool options, so that one can say:
#! /usr/bin/dh-exec --without-subst
Or:
#! /usr/bin/dh-exec --with-install
By the way, the current state of my work (renamed from dh-subst to
dh-exec) is available at https://github.com/algernon/dh-exec/ (the URL
may change, if the project gets renamed again), if you or anyone else
feels like giving it a test ride.
There's even a debian/ dir in there, and a test suite (just don't look
at the test scripts... I need to rewrite those)!
--
|8]
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcpl4ps4.fsf@algernon.balabit
Re: Getting dh_install to do what we need
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: it will first try the source file directly, and if it's
> | # not found, try the same path under debian/tmp/. The destination is
> | # relative to debian/${PACKAGE} (as per dh compat level 7+)
> | #
> | # Since dh-exec-install does the copying itself, this line is NOT
> | # echoed back to dh_install.
> | source-file /dest-dir/new-name
> `
Of course the reason I didn't add this to dh_install 10 years ago is
that this syntax sucks. It's really horrible; either the trailing slashes
are much more significant than makes sense, or what it does depends on
the state of the filesystem(ie, checking whether /dest-dir/new-name is
a directory).
> My implementation copies the file to the desired destination, which may
> or may not be a good idea - I'll do some more tests to see which one's
> less painful and more safe.
That breaks -X, --fail-missing, --list-missing, --sourcedir, and --tmpdir
--
see shy jo
signature.asc
Description: Digital signature
Re: Red Hat is moving from / to /usr/
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. No raid then mdadm isn't included. No lvm > >> and the initramfs gets smaller again. And only select modules for > >> one kernel are in there. Huge space saving again. So an initramfs > >> will/can be minimal. > > > > I assume this means it will be impossible to swap the hdd from one > > system to another without rebuilding the initramfs? Seems like a > > step backwards for flexability. > > Trimming the initramfs is an *optional* feature. > > cf. /etc/initramfs-tools/initramfs.conf Thanks for clearing that up. kk -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Re: options: was Red Hat is moving from / to /usr/
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 wanted all the config for /usr to be in /etc/usr (which is a symlink to /usr/etc) for a long time. But, by the time anyone hear of efforts such as this, there seldom seems to be time to stop them. Hence, my question is, if this continues to happen, what do we move to for a kernel? Free-BSD? Plan 9? Something else? Is anyone working on a migration scheme? -- Gord -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112121855.19263.ghave...@materialisations.com
Re: options: was Red Hat is moving from / to /usr/
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/* still exist today. Which reasons? They changed from time to time. Last time I looked, on a Debian system /sbin did not contain statically-linked binaries. > I want more segregation, not less. Actually, I've wanted all the > config for /usr to be in /etc/usr (which is a symlink to /usr/etc) > for a long time. > > But, by the time anyone hear of efforts such as this, there seldom > seems to be time to stop them. > > Hence, my question is, if this continues to happen, what do we > move to for a kernel? Free-BSD? Plan 9? Something else? Is > anyone working on a migration scheme? FreeBSD userland is largely a throwback to the 90s, so it's probably just what you're looking for. Plan 9 has precisely the unification you so hate. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
