[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Marc Schiffbauer posted on Wed, 04 Jan 2012 21:45:35 +0100 as excerpted: > Please remember that there are *way* more server systems running linux > without any graphical desktop at all than desktop systems. So with Google activating ~800k android Linux systems a day last I heard, how do the number of (android) Linux systems (which we've already established as having dbus) compare to the number of server Linux systems? If traditional gnu-linux isn't a minority in its own community already, it soon will be. I sympathize with the sentiment behind the argument, but the numbers game really doesn't cut it, or we'd all be running some binary distribution or other instead of from-source Gentoo and we'd not be having this discussion as it would have already been had for us. (Yeah, there IS rather a lot to be read between THOSE lines!) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Jeroen Roovers wrote: On Sun, 01 Jan 2012 16:49:42 -0500 Olivier Crête wrote: That's why you have dracut to do it for you. Which is keyworded at this point. Stable users do what? It's keyworded for only two arches. And amd64 is one of them. I'd say it is a fairly popular arch too. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
* Olivier Crête schrieb am 04.01.12 um 22:55 Uhr: > On Wed, 2012-01-04 at 21:45 +0100, Marc Schiffbauer wrote: > > > > > That said, in the new systemd world, bash is.. Since it's only a > > "UI" > > > tools (just like gnome-shell for example). Since you don't need it > > to > > > boot. > > > > Yeah right. Having dbus for bluetooth is much more important than > > having a shell. > > > > Please remember that there are *way* more server systems running > > linux > > without any graphical desktop at all than desktop systems. > > Please remember that servers and desktops are dwarfed by the number of > embedded systems running Linux. Probably more devices are sold running > Linux in a single day than the total number of servers in the world... Yes, but these do most propably never run some stock distro. > But well, this isn't a number's game. D-Bus is the system bus and > bluetooth is just one example of a system level component that uses it. ... which is not really required to boot a system. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgplq0ahIKQFg.pgp Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 01 Jan 2012 16:49:42 -0500 Olivier Crête wrote: > > > That's why you have dracut to do it for you. > > Which is keyworded at this point. Stable users do what? It's keyworded for only two arches. > This is a discussion about the future... Changing keywords is trivial > if we care. Oh, let's quickly drop the notion of arch testing/stabilisation. :) jer
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 01/04/2012 09:32 AM, Olivier Crête wrote: > On Wed, 2012-01-04 at 18:12 +0100, Ulrich Mueller wrote: >>> On Wed, 4 Jan 2012, Michał Górny wrote: >> What mistakes? >> >>> The mistake of introducing a pointless separation based on a rule of >>> thumb which becomes more and more blurry over time, and hacking >>> packages just to make it work. >> >> There's really nothing pointless or blurry about this separation. >> The FHS has a nice definition: "The contents of the root filesystem >> must be adequate to boot, restore, recover, and/or repair the system." > > The problem is that to boot a modern system, you need a shitload of > stuff. For example, modern network filesystems often have secure > authentication and probably LDAP too, so that means we need to move ldap > and openssl into / and all the dependencies. Also, anything that > installs a udev rule needs to be in /, and the list goes on an on. Very > soon, you have almost everything in /... > > This rule made sense in the 80s, but it doesn't match the modern world > anymore. > > Some longer explanations: > http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > https://fedoraproject.org/wiki/Features/UsrMove The FHS notion of "root filesystem as a recovery partition" existed long before the relatively modern development of things like busybox and initramfs made it more practical to use an initramfs as a recovery partition. Anyone who wouldn't prefer to use an initramfs for their "recover partition" probably just doesn't realize how well suited an initramfs is for the job. It's so well suited for the job that it makes the old FHS notion of "root filesystem as a recovery partition" seem quaint. -- Thanks, Zac
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 21:45 +0100, Marc Schiffbauer wrote: > > > That said, in the new systemd world, bash is.. Since it's only a > "UI" > > tools (just like gnome-shell for example). Since you don't need it > to > > boot. > > Yeah right. Having dbus for bluetooth is much more important than > having a shell. > > Please remember that there are *way* more server systems running > linux > without any graphical desktop at all than desktop systems. Please remember that servers and desktops are dwarfed by the number of embedded systems running Linux. Probably more devices are sold running Linux in a single day than the total number of servers in the world... But well, this isn't a number's game. D-Bus is the system bus and bluetooth is just one example of a system level component that uses it. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
* Olivier Crête schrieb am 04.01.12 um 19:53 Uhr: > On Wed, 2012-01-04 at 19:30 +0100, Marc Schiffbauer wrote: > > * Olivier Crête schrieb am 04.01.12 um 18:40 Uhr: > > > On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: > > > > On Wed, 4 Jan 2012 16:51:12 +0100 > > > > Michał Górny wrote: > > > > > /bin/systemctl > > > > > libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 > > > > > > > > Here is a prime example of why "vertical integration" should really be > > > > called "a horrible mess of tight coupling"... > > > > > > You clearly have failed to realize that d-bus is a now the bus for > > > system messaging and is as much part of the system as syslog or bash. > > > Probably even more so, for example, in Fedora 17, you'll be able to boot > > > without syslog or bash, but you need d-bus. > > > > If this was true, we will soon have problems with linux systems that > > windows had in 1995. > > > > IMO a system should *always* be bootable without that "high level" > > stuff. And by bootable I mean that you can get a root prompt at > > least. > > d-bus is not high-level stuff... For example, you can't use bluetooth > without d-bus. Even Android has it.. And you need bluetooth to boot your stable datacenter server systems? > That said, in the new systemd world, bash is.. Since it's only a "UI" > tools (just like gnome-shell for example). Since you don't need it to > boot. Yeah right. Having dbus for bluetooth is much more important than having a shell. Please remember that there are *way* more server systems running linux without any graphical desktop at all than desktop systems. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpWXb157aI0g.pgp Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 04, 2012 at 07:26:05PM +0100, Marc Schiffbauer wrote: > For example, to make that FHS definition be reality there are (can > be) runlevels that will only boot a system with all basic stuff > required to mount the rootfs and make root being able to login to > the local text console. These are the things that make a unixoid > system valuable over other kind of systems. There are benefits to the proposed changes, especially for rpm based distros and especially for non-server settings. Are they good enough? No, I don't think they are. But since forking all those packages is not a realistic proposition, we will have to follow along. We should try and not break existing installations when we do though. > I do not like the idea to throw away all those benefits just because > so many (younger/newer) people do not know about the possibilities > an "old fashioned" unix system tends to have. Hey, this is web 2.0 era. Being mostly right most of the time is good enough. -- Eray Aslan signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 04-01-2012 20:26:27 +0100, Michał Górny wrote: > We use hacks to move shared libraries to rootfs, and then create one > more hack to not confuse the linker with different locations of static > and shared libraries. So your point is that the reasons why this was originally done are now no longer valid, because...? -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 04-01-2012 20:28:01 +0100, Michał Górny wrote: > > > And a compiler. If I mess up some important system component, I'd > > > really use one. And package manager. And backup system libraries... > > > > Time for your PXE boot from net to just bring back a sane image or so. > > My PXE boot from net won't happen because possible /usr-over-NFS relies > on random files from other rootfs, and they just failed to be in sync > between two of my systems. Seems like you've got a situation where you'd just shove in a livecd then. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 20:00:51 +0100 Fabian Groffen wrote: > On 04-01-2012 19:50:24 +0100, Michał Górny wrote: > > On Wed, 4 Jan 2012 18:12:18 +0100 > > Ulrich Mueller wrote: > > > > > > On Wed, 4 Jan 2012, Michał Górny wrote: > > > > > > >> What mistakes? > > > > > > > The mistake of introducing a pointless separation based on a > > > > rule of thumb which becomes more and more blurry over time, and > > > > hacking packages just to make it work. > > > > > > There's really nothing pointless or blurry about this separation. > > > The FHS has a nice definition: "The contents of the root > > > filesystem must be adequate to boot, restore, recover, and/or > > > repair the system." > > > > Why don't we have sshd there then? I don't really feel like > > repairing remote system without fallback sshd. > > Network isn't typically in that bootlevel. You'd just attach through > the console (netmgt, ipmi, keyboard/vga) instead. > > > And a compiler. If I mess up some important system component, I'd > > really use one. And package manager. And backup system libraries... > > Time for your PXE boot from net to just bring back a sane image or so. My PXE boot from net won't happen because possible /usr-over-NFS relies on random files from other rootfs, and they just failed to be in sync between two of my systems. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 04 Jan 2012 19:48:03 +0100 Thomas Sachau wrote: > Defining a prefix is no "hack", it is an option you can use. > > Anyway, we both have probably enough packages with such a "hack" > installed, but i cannot find a single file in /lib/pkgconfig, not even > that dir does exist. Is it different on your system? Defining a prefix is no hack. Defining a prefix would result in existence of such a file, and installation of static libraries in /lib. We use hacks to move shared libraries to rootfs, and then create one more hack to not confuse the linker with different locations of static and shared libraries. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 04-01-2012 13:51:26 -0500, Olivier Crête wrote: > No no no, the idea is that once all binaries are in /usr, you can easily > share /usr between different systems and do updates in a sane way.. You > can also mount /usr read-only, but still have / be read-write. http://article.gmane.org/gmane.linux.debian.devel.general/165891 -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 04-01-2012 19:50:24 +0100, Michał Górny wrote: > On Wed, 4 Jan 2012 18:12:18 +0100 > Ulrich Mueller wrote: > > > > On Wed, 4 Jan 2012, Michał Górny wrote: > > > > >> What mistakes? > > > > > The mistake of introducing a pointless separation based on a rule of > > > thumb which becomes more and more blurry over time, and hacking > > > packages just to make it work. > > > > There's really nothing pointless or blurry about this separation. > > The FHS has a nice definition: "The contents of the root filesystem > > must be adequate to boot, restore, recover, and/or repair the system." > > Why don't we have sshd there then? I don't really feel like repairing > remote system without fallback sshd. Network isn't typically in that bootlevel. You'd just attach through the console (netmgt, ipmi, keyboard/vga) instead. > And a compiler. If I mess up some important system component, I'd really > use one. And package manager. And backup system libraries... Time for your PXE boot from net to just bring back a sane image or so. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 1:27 PM, Kent Fredric wrote: > Given that these tools are being moved to /usr and/or duplicated to in > initrd , what is the point of a root filesystem anyway now? Just to > mount other things on? Just to store /etc ? > > Or will /etc move to /usr too? I'd recommend reading the fedora docs. Their plan is to make /usr read-only so that it contains all elements of the system managed by the distro. In the future rpm world config files exist half on /usr, with overriding content in /etc (they don't have etc-update, and etc-update isn't always perfect either). But yes, the trend is towards making rootfs a bit more "virtual." I can see some of the benefits of this arrangement, but by the time we get that all worked out btrfs might be practical, and its subvolumes actually solve many of the problems that lvm and many partitions are used to solve today. With btrfs you can make /usr a subvolume and snapshot it at will, or set up a quota just for it. That doesn't cover all the use cases, but it does cover most of the desktop-y ones. As far as repairing the system from rootfs goes - I think that greatly depends on your circumstances. If everything is on root anyway then it is a moot point. If everything isn't on root then your ability to recover is inversely proportional to the complexity of your systems. As others have pointed out, there is always something that you won't have, and to be honest it isn't all that hard to just boot a liveDVD that has everything and the kitchen sink available anyway. Rich
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 19:30 +0100, Marc Schiffbauer wrote: > * Olivier Crête schrieb am 04.01.12 um 18:40 Uhr: > > On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: > > > On Wed, 4 Jan 2012 16:51:12 +0100 > > > Michał Górny wrote: > > > > /bin/systemctl > > > > libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 > > > > > > Here is a prime example of why "vertical integration" should really be > > > called "a horrible mess of tight coupling"... > > > > You clearly have failed to realize that d-bus is a now the bus for > > system messaging and is as much part of the system as syslog or bash. > > Probably even more so, for example, in Fedora 17, you'll be able to boot > > without syslog or bash, but you need d-bus. > > If this was true, we will soon have problems with linux systems that > windows had in 1995. > > IMO a system should *always* be bootable without that "high level" > stuff. And by bootable I mean that you can get a root prompt at > least. d-bus is not high-level stuff... For example, you can't use bluetooth without d-bus. Even Android has it.. That said, in the new systemd world, bash is.. Since it's only a "UI" tools (just like gnome-shell for example). Since you don't need it to boot. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 07:27 +1300, Kent Fredric wrote: > 2012/1/5 Ulrich Mueller > > > > > On Wed, 4 Jan 2012, Michał Górny wrote: > >> > > There's really nothing pointless or blurry about this separation. > > The FHS has a nice definition: "The contents of the root filesystem > > must be adequate to boot, restore, recover, and/or repair the system." > > > > Given that these tools are being moved to /usr and/or duplicated to in > initrd , what is the point of a root filesystem anyway now? Just to > mount other things on? Just to store /etc ? > > Or will /etc move to /usr too? > > /usr/etc somewhat horrifies me. No no no, the idea is that once all binaries are in /usr, you can easily share /usr between different systems and do updates in a sane way.. You can also mount /usr read-only, but still have / be read-write. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 18:12:18 +0100 Ulrich Mueller wrote: > > On Wed, 4 Jan 2012, Michał Górny wrote: > > >> What mistakes? > > > The mistake of introducing a pointless separation based on a rule of > > thumb which becomes more and more blurry over time, and hacking > > packages just to make it work. > > There's really nothing pointless or blurry about this separation. > The FHS has a nice definition: "The contents of the root filesystem > must be adequate to boot, restore, recover, and/or repair the system." Why don't we have sshd there then? I don't really feel like repairing remote system without fallback sshd. And a compiler. If I mess up some important system component, I'd really use one. And package manager. And backup system libraries... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny schrieb: > On Wed, 04 Jan 2012 13:06:11 +0100 > Thomas Sachau wrote: > >> Michał Górny schrieb: >>> On Wed, 04 Jan 2012 01:47:38 +0100 >>> Thomas Sachau wrote: >>> 2. switching from udev to mdev (avoids required /usr of udev) 3. some wrapper script to mount /usr before udev starts >>> >>> These two should be really discouraged as a cheap, temporary >>> solution. We should not support hate-admining. I personally think >>> that busybox is ready to go into /usr even earlier than udev. >> >> Please give us a bit more than just your opinion. >> >> Why do you see mdev as a temporary solution? > > Because we will then return to this discussion at some later point > and people will start throwing excrements at us again. So let's be done > with this at once. Please tell me, how a replacement for udev, which in the end removes the requirement for mounted /usr at boot time, should later require a mounted /usr again. And please dont tell me, that this will happen because you moved everything to /usr. This is something you would like to do and wish to see, but i dont see it happen. > >> And this part was not about the movement to /usr at all, so why do you >> suggest another movement here? And while you answer that, please also >> tell us, why you want to migrate packages to a different install >> location without a need. > > Because we need to finally be able to fix mistakes made in the past > by other people. This has already been commented on by grobian and ulm, so i see no need to dublicate their lines. For the idea of complete migration to /usr, i see no reason to go this route in advance. Just keep with our default install locations and follow upstream, if and where needed. >>> >>> What about upstreams who do not care? In other words, all those >>> packages which we hack to install into rootfs? >> >> They install and work fine, so just keep it this way. I did not see >> any argument to move packages around, that work well and have no >> issue with their current install location. > > What if, say, upstream introduces pkg-config file where our hacks will > cause it to be installed into /lib/pkgconfig? Should we then expand > the hack to cover that, and something else, and then another thing... Defining a prefix is no "hack", it is an option you can use. Anyway, we both have probably enough packages with such a "hack" installed, but i cannot find a single file in /lib/pkgconfig, not even that dir does exist. Is it different on your system? If not, then please tell me, why you create some theory about possible issues, which dont even exist. Dont you have better arguments for your suggested move to /usr? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 5 Jan 2012 07:27:49 +1300 Kent Fredric wrote: > 2012/1/5 Ulrich Mueller > > > > > On Wed, 4 Jan 2012, Michał Górny wrote: > >> > > There's really nothing pointless or blurry about this separation. > > The FHS has a nice definition: "The contents of the root filesystem > > must be adequate to boot, restore, recover, and/or repair the > > system." > > > > Given that these tools are being moved to /usr and/or duplicated to in > initrd , what is the point of a root filesystem anyway now? Just to > mount other things on? Just to store /etc ? Well, you can either keep both /etc and /usr on a single filesystem, or move /etc out of rootfs and just make it a tmpfs. > And if you no longer have a suite of recovery tools on root, you > *have* to really have a copy in initrd, otherwise when /usr gets > damaged and needs repaired/recovered, you'll need a boot disk just to > solve that problem. And that I don't fancy. And if / gets damaged, keeping those tools on / doesn't help either. If you have them on initramfs, they can fix it as well. Of course we could go onto 'what if initramfs gets damaged?' but then you're HDD got damaged as well... > And another errant thought: why not just repurpose the initrd as "the > root filesystem" if the root filesystem is just to exist for the > purpose of bolting other stuff on. Noone forbids you to. But then you won't get your memory back when real system boots. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
* Olivier Crête schrieb am 04.01.12 um 18:40 Uhr: > On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: > > On Wed, 4 Jan 2012 16:51:12 +0100 > > Michał Górny wrote: > > > /bin/systemctl > > > libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 > > > > Here is a prime example of why "vertical integration" should really be > > called "a horrible mess of tight coupling"... > > You clearly have failed to realize that d-bus is a now the bus for > system messaging and is as much part of the system as syslog or bash. > Probably even more so, for example, in Fedora 17, you'll be able to boot > without syslog or bash, but you need d-bus. If this was true, we will soon have problems with linux systems that windows had in 1995. IMO a system should *always* be bootable without that "high level" stuff. And by bootable I mean that you can get a root prompt at least. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpHP0cF1oZ61.pgp Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
2012/1/5 Ulrich Mueller > > > On Wed, 4 Jan 2012, Michał Górny wrote: >> > There's really nothing pointless or blurry about this separation. > The FHS has a nice definition: "The contents of the root filesystem > must be adequate to boot, restore, recover, and/or repair the system." > Given that these tools are being moved to /usr and/or duplicated to in initrd , what is the point of a root filesystem anyway now? Just to mount other things on? Just to store /etc ? Or will /etc move to /usr too? /usr/etc somewhat horrifies me. And if you no longer have a suite of recovery tools on root, you *have* to really have a copy in initrd, otherwise when /usr gets damaged and needs repaired/recovered, you'll need a boot disk just to solve that problem. And that I don't fancy. And another errant thought: why not just repurpose the initrd as "the root filesystem" if the root filesystem is just to exist for the purpose of bolting other stuff on. Because in my mind, the primary benefit of initrd over an actual filesystem is the initrd is theoretically a lot harder to mess up, and you can easily have a plethora of alternative known-good initrd's to fall back on. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
* Olivier Crête schrieb am 04.01.12 um 18:32 Uhr: > On Wed, 2012-01-04 at 18:12 +0100, Ulrich Mueller wrote: > > > On Wed, 4 Jan 2012, Michał Górny wrote: > > > > >> What mistakes? > > > > > The mistake of introducing a pointless separation based on a rule of > > > thumb which becomes more and more blurry over time, and hacking > > > packages just to make it work. > > > > There's really nothing pointless or blurry about this separation. > > The FHS has a nice definition: "The contents of the root filesystem > > must be adequate to boot, restore, recover, and/or repair the system." > > The problem is that to boot a modern system, you need a shitload of > stuff. To boot the system on its highest level: yes. But Linux/UNIX systems have a concept called runlevels that can perfectly cover cases where this "shitload of stuff" is not required. For example, to make that FHS definition be reality there are (can be) runlevels that will only boot a system with all basic stuff required to mount the rootfs and make root being able to login to the local text console. These are the things that make a unixoid system valuable over other kind of systems. > For example, modern network filesystems often have secure > authentication and probably LDAP too, so that means we need to move ldap > and openssl into / and all the dependencies. Also, anything that > installs a udev rule needs to be in /, and the list goes on an on. Very > soon, you have almost everything in /... You do not need everything to make a system boot some sort of recovery-console for example. > > This rule made sense in the 80s, but it doesn't match the modern world > anymore. Why? The benefits to keep a system bootable and repairable is one of the reasons why unix systems are more robust or can better be repeaired than, lets say windows systems for example. I do not like the idea to throw away all those benefits just because so many (younger/newer) people do not know about the possibilities an "old fashioned" unix system tends to have. -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 pgpkTWMsEkKlm.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: rfc: locations of binaries and separate /usr
On Wed, Jan 04, 2012 at 03:19:57PM +, Steven J Long wrote: > I could swear we were told in prior discussions on this list that a separate > /usr partition is not considered supported by upstream udev, but searching > all I can find is that an initramfs is required.[1] The upstream statement was more specifically that: starting udev (or systemd) without /usr available was not considered supported. If /usr is on a separate partition, this is forcing us down the initramfs route (If fsck ends up on /usr, the only way to fsck /usr is from an extra copy in the initramfs...). -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 04 Jan 2012 12:40:10 -0500 Olivier Crête wrote: > On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: > > On Wed, 4 Jan 2012 16:51:12 +0100 > > Michał Górny wrote: > > > /bin/systemctl > > > libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 > > > > Here is a prime example of why "vertical integration" should really > > be called "a horrible mess of tight coupling"... > > You clearly have failed to realize that d-bus is a now the bus for > system messaging and is as much part of the system as syslog or bash. > Probably even more so, for example, in Fedora 17, you'll be able to > boot without syslog or bash, but you need d-bus. No, I realise full well that some GnomeOS developers would like us to think that HAL, D-BUS, network-manager, udev-extras etc are part of the system, and are sloppily writing code that makes that assumption. However, the question ultimately under discussion is whether Gentoo is to be a Linux distribution or a GnomeOS distribution. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: > On Wed, 4 Jan 2012 16:51:12 +0100 > Michał Górny wrote: > > /bin/systemctl > > libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 > > Here is a prime example of why "vertical integration" should really be > called "a horrible mess of tight coupling"... You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. -- Olivier Crête tes...@gentoo.org Gentoo Developer
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 18:12 +0100, Ulrich Mueller wrote: > > On Wed, 4 Jan 2012, Michał Górny wrote: > > >> What mistakes? > > > The mistake of introducing a pointless separation based on a rule of > > thumb which becomes more and more blurry over time, and hacking > > packages just to make it work. > > There's really nothing pointless or blurry about this separation. > The FHS has a nice definition: "The contents of the root filesystem > must be adequate to boot, restore, recover, and/or repair the system." The problem is that to boot a modern system, you need a shitload of stuff. For example, modern network filesystems often have secure authentication and probably LDAP too, so that means we need to move ldap and openssl into / and all the dependencies. Also, anything that installs a udev rule needs to be in /, and the list goes on an on. Very soon, you have almost everything in /... This rule made sense in the 80s, but it doesn't match the modern world anymore. Some longer explanations: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken https://fedoraproject.org/wiki/Features/UsrMove Here is a list of packages on your system that will break if you start udev without /usr mounted: egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* |cut -f 1 -d : | sort -u | xargs qfile -e -- Olivier Crête tes...@gentoo.org Gentoo Developer
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
> On Wed, 4 Jan 2012, Michał Górny wrote: >> What mistakes? > The mistake of introducing a pointless separation based on a rule of > thumb which becomes more and more blurry over time, and hacking > packages just to make it work. There's really nothing pointless or blurry about this separation. The FHS has a nice definition: "The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system." Ulrich
[gentoo-dev] Re: Exorcising a d(a)emon from GNOME's past (aka EsounD Last Rites)
On Wed, Jan 4, 2012 at 9:03 PM, Mikko C. wrote: > Hi, > for me removing esound causes Thunderbird to not play sounds anymore. > Related bug is https://bugzilla.mozilla.org/show_bug.cgi?id=378155 > Also googling for "esound + thunderbird" yields quite a few results related > to this. The bug is quite clear on the status. The problem is with Thunderbird, which is not supposed to be using esound at all. Infact our thunderbird ebuilds don't even depend on esound => not a blocker for esound removal. It should use Alsa (libasound) or libcanberra to play sounds, which it obviously doesn't. No other distribution ships esound anymore, and if Thunderbird is being idiotic, it's upto their devs to fix the bug. Quite frankly, I'm shocked that Thunderbird *STILL* has code that depends on esound for playing wav files. Esound was deprecated half a decade ago. Thanks for reporting this bug! I'll keep track of it now and try to get it fixed. On Wed, Jan 4, 2012 at 6:48 AM, Nirbheek Chauhan wrote: > Hi folks, > > Today, I was shocked to find that the EsounD daemon is still in the > tree and new ebuilds are actually still pulling it in under USE=esd! > > Proposal: package.mask media-sound/esound, use.mask USE=esd. Anything > that still uses it should stop using it. Anything that /needs it/ > should be purged from the tree with extreme prejudice[1]. > > I'll do the first two today, and the rest of the rituals necessary to > complete the exorcism will take a month. Help in this regard is > welcome since the job is rather straightforward. > > Thanks! > > 1. In exceptional cases, a dependency on pulseaudio will also suffice > since pulseaudio emulates an esound socket while running with > `module-protocol-esound-unix` loaded, which is the default. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 17:33:15 +0100 Fabian Groffen wrote: > On 04-01-2012 16:37:34 +0100, Michał Górny wrote: > > > And this part was not about the movement to /usr at all, so why > > > do you suggest another movement here? And while you answer that, > > > please also tell us, why you want to migrate packages to a > > > different install location without a need. > > > > Because we need to finally be able to fix mistakes made in the past > > by other people. > > What mistakes? The mistake of introducing a pointless separation based on a rule of thumb which becomes more and more blurry over time, and hacking packages just to make it work. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 04-01-2012 16:37:34 +0100, Michał Górny wrote: > > And this part was not about the movement to /usr at all, so why do you > > suggest another movement here? And while you answer that, please also > > tell us, why you want to migrate packages to a different install > > location without a need. > > Because we need to finally be able to fix mistakes made in the past > by other people. What mistakes? > > They install and work fine, so just keep it this way. I did not see > > any argument to move packages around, that work well and have no > > issue with their current install location. > > What if, say, upstream introduces pkg-config file where our hacks will > cause it to be installed into /lib/pkgconfig? Should we then expand > the hack to cover that, and something else, and then another thing... Highly unlikely, but if it happens, easy to fix, so not really a convincing issue. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 15:54:07 + Ciaran McCreesh wrote: > On Wed, 4 Jan 2012 16:51:12 +0100 > Michał Górny wrote: > > /bin/systemctl > > libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 Considering that I really thought about stripping that one because otherwise people will not even notice the other page of results. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny wrote: > /bin/systemctl > libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 Here is a prime example of why "vertical integration" should really be called "a horrible mess of tight coupling"... Remember how people used to make fun of Windows when it would fail to boot if you broke Internet Explorer? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 04 Jan 2012 13:50:45 + Steven J Long wrote: > (Additionally I'd say that binaries installed to /bin that require > libraries installed to /usr is a bug, but something that should be > dealt with separately. Though with the direction people seem to think > is needed, I'm not sure how much effort anyone will put into that.) /bin/bsdcpio libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x7fa3c89e3000) liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x7fa3c7be9000) libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x7fa3c7418000) /bin/expr libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x7f7cf26cc000) /bin/findmnt libmount.so.1 => /usr/lib64/libmount.so.1 (0x7fa23d614000) /bin/grub2-mkfont libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x7f1007a4c000) /bin/grub2-mkimage liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x7fa60d479000) /bin/lowntfs-3g libfuse.so.2 => /usr/lib64/libfuse.so.2 (0x7f912ed48000) /bin/mail liblockfile.so.1 => /usr/lib64/liblockfile.so.1 (0x7fb8e249c000) /bin/systemctl libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x7f6cfdf4c000) /sbin/audisp-remote libcap-ng.so.0 => /usr/lib64/libcap-ng.so.0 (0x7fbd76aae000) /sbin/irqbalance libcap-ng.so.0 => /usr/lib64/libcap-ng.so.0 (0x7fc5b8eb3000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x7fc5b8b92000) /sbin/rpcbind libgssglue.so.1 => /usr/lib64/libgssglue.so.1 (0x7fb209614000) (and I tried not to list more than one file from a single package) The list could be longer if I enabled more USE flags, I think. And for example, I could see benefits of having sshd on rootfs as well, if we kept the old definition of it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 04 Jan 2012 13:06:11 +0100 Thomas Sachau wrote: > Michał Górny schrieb: > > On Wed, 04 Jan 2012 01:47:38 +0100 > > Thomas Sachau wrote: > > > >> 2. switching from udev to mdev (avoids required /usr of udev) > >> 3. some wrapper script to mount /usr before udev starts > > > > These two should be really discouraged as a cheap, temporary > > solution. We should not support hate-admining. I personally think > > that busybox is ready to go into /usr even earlier than udev. > > Please give us a bit more than just your opinion. > > Why do you see mdev as a temporary solution? Because we will then return to this discussion at some later point and people will start throwing excrements at us again. So let's be done with this at once. > And this part was not about the movement to /usr at all, so why do you > suggest another movement here? And while you answer that, please also > tell us, why you want to migrate packages to a different install > location without a need. Because we need to finally be able to fix mistakes made in the past by other people. > >> For the idea of complete migration to /usr, i see no reason to go > >> this route in advance. Just keep with our default install > >> locations and follow upstream, if and where needed. > > > > What about upstreams who do not care? In other words, all those > > packages which we hack to install into rootfs? > > They install and work fine, so just keep it this way. I did not see > any argument to move packages around, that work well and have no > issue with their current install location. What if, say, upstream introduces pkg-config file where our hacks will cause it to be installed into /lib/pkgconfig? Should we then expand the hack to cover that, and something else, and then another thing... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 10:19 AM, Steven J Long wrote: > I was under the impression that anyone using lvm+raid (+luks) on root > already has an initramfs, and there are docs out there about that, but sure, > improving those docs and the software is always a good idea. Anybody running root on lvm+raid(+luks) is already using an initramfs. However, the guide I linked does not run root on lvm/luks - just on raid1, which does not require an initramfs. That guide puts everything BUT root on LVM, assuming that baselayout/sysvinit/openrc on root can mount everything else. The existing initramfs tools do not yet mount /usr regardless. I'm sure RedHat and others pursing a read-only /usr required at time of boot will be looking to rectify this, so Gentoo is moving along with upstream for dracut/etc here. > Yeah I've been using lvm for several years now, with a separate /usr and no > initramfs, though not on root. For the last few months, I've been running > with the tweaked udev startup scripts I mentioned before, so /usr is mounted > before udev starts (which is possible since I don't have any requirement on > udev-initialised hardware to mount local drives.) That's basically my configuration as well. However, I don't really want to set the goal of making Gentoo support my own configuration. In any case, having a more robust initramfs solution for separate /usr should support this and many other configurations. > > Regardless of the ability to backup just /usr, I'm still not convinced about > moving every binary there. It certainly isn't necessary, in that the > packages we install respect prefix, and there's no need to change the > ebuilds to make packages work; further most admins already have their own > backup scripts in-place. I think that the path of least resistance is to move with upstream - let's not try to force everything into /usr unless that becomes a consensus with many other distros. However, we can at least look to accomodate things like udev that are moving in this direction so that it doesn't create sparks within Gentoo. > > I for one, would like to be able to run in single-user mode off just the > rootfs, in case for instance, something goes wrong with lvm and /usr won't > mount; and I don't want to duplicate all those utilities in an initramfs. If > that's not going to be possible, fair enough: that's life. > I hear you. No harm in supporting this as long as seems reasonable, but you're going to be stuck without udev from the sound of things, and that is a lot to lose. You should give dracut a shot - it does quite a bit automagically though for some reason it doesn't set up my raid properly (I can do it with a simple mdadm --assemble --scan from the dracut shell), and it doesn't mount /usr yet. So, it isn't there, but it does quite a bit just the same. Rich
[gentoo-dev] Re: Re: rfc: locations of binaries and separate /usr
Rich Freeman wrote: > On Wed, Jan 4, 2012 at 8:50 AM, Steven J Long > wrote: >> The thing I don't understand is why it is necessary to move stuff from >> /bin to /usr/bin. After all, if you're running the "approved" setup you >> don't have a separate /usr so all the binaries are available from the >> get-go. > > Where is this approved setup documented? I could swear we were told in prior discussions on this list that a separate /usr partition is not considered supported by upstream udev, but searching all I can find is that an initramfs is required.[1] Having read the other page[2] that has been pointed out, the answer to my question "what does this enable that we can't do currently?" is: snapshotting the OS by backing up just the /usr partition. I can see the attraction in that, especially for organisations. Though it does make me smile that it depends on having a separate /usr partition to work. ;) The whole saga has just seemed confused to me: one minute a separate /usr is a terrible idea, the next we have to move every binary to /usr in order to snapshot a separate /usr. Loath as I am to agree with him, I have to concur with Ciaran McCreesh that this is "a case of carelessly letting the horse escape and then trying to convince everyone that no-one needs a horse anyway."[3] > Well, it is hard to think of a meaningful raid+lvm configuration that > doesn't require an initramfs of some sort with the dependence on files > in /usr during boot. So, getting our initramfs options improved and > supporting this configuration just makes sense regardless before we > unmask newer versions of udev. > I was under the impression that anyone using lvm+raid (+luks) on root already has an initramfs, and there are docs out there about that, but sure, improving those docs and the software is always a good idea. > Raid+lvm isn't exactly an unusual use-case. Many distros actually use > at least lvm by default now. > Yeah I've been using lvm for several years now, with a separate /usr and no initramfs, though not on root. For the last few months, I've been running with the tweaked udev startup scripts I mentioned before, so /usr is mounted before udev starts (which is possible since I don't have any requirement on udev-initialised hardware to mount local drives.) Regardless of the ability to backup just /usr, I'm still not convinced about moving every binary there. It certainly isn't necessary, in that the packages we install respect prefix, and there's no need to change the ebuilds to make packages work; further most admins already have their own backup scripts in-place. I for one, would like to be able to run in single-user mode off just the rootfs, in case for instance, something goes wrong with lvm and /usr won't mount; and I don't want to duplicate all those utilities in an initramfs. If that's not going to be possible, fair enough: that's life. [1] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken [2] http://fedoraproject.org/wiki/Features/UsrMove [3] http://article.gmane.org/gmane.linux.gentoo.devel/72130 -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 8:50 AM, Steven J Long wrote: > The thing I don't understand is why it is necessary to move stuff from /bin > to /usr/bin. After all, if you're running the "approved" setup you don't > have a separate /usr so all the binaries are available from the get-go. Where is this approved setup documented? Consider guides like this one: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml While you're fixing that you might want to write up an "easy migration guide" for anybody who followed our official docs in "the past" (with "the past" including up to the moment that the raid+lvm guide is updated)... > Sure, if you have binaries in /bin that link to libraries in /usr/lib that > could be an issue, but only if you're running with a separate /usr and don't > have it mounted when udev starts. So again, not the "approved" setup, and > something you as an admin already have to deal with by making sure /usr is > mounted when udev starts (either via an initramfs, or by a tweak to udev > startup scripts[1].) Well, it is hard to think of a meaningful raid+lvm configuration that doesn't require an initramfs of some sort with the dependence on files in /usr during boot. So, getting our initramfs options improved and supporting this configuration just makes sense regardless before we unmask newer versions of udev. Raid+lvm isn't exactly an unusual use-case. Many distros actually use at least lvm by default now. Rich
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
Michał Górny wrote: > On Sun, 1 Jan 2012 08:53:26 + > Sven Vermeulen wrote: > >> On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote: >> > The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My >> > understanding is that they want to move software that is installed >> > in /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move >> > everything from /lib to /usr/lib. >> >> I don't like this one bit. Things used to be simple with the "split" >> between /bin and /usr/bin (and its related directories), this isn't >> going to make it more simple. > > Simple? Should I start requesting additional packages moved into rootfs > because I feel like needing them? Things can and will go more ugly, > and I wouldn't be surprised if anytime soon people will start > complaining because they ran out of space on their rootfs. > Well, it is conceptually quite simple: if it's needed in single-user mode to get your system up and running again, it belongs in rootfs, and if it isn't, then leave it in user-land. The thing I don't understand is why it is necessary to move stuff from /bin to /usr/bin. After all, if you're running the "approved" setup you don't have a separate /usr so all the binaries are available from the get-go. What does moving them enable that can't be done now? Sure, if you have binaries in /bin that link to libraries in /usr/lib that could be an issue, but only if you're running with a separate /usr and don't have it mounted when udev starts. So again, not the "approved" setup, and something you as an admin already have to deal with by making sure /usr is mounted when udev starts (either via an initramfs, or by a tweak to udev startup scripts[1].) wrt GNU coreutils installing to /usr by default, that's so of every GNU package, since they default to a prefix of /usr/local and it's up to a distro (or the end-user) to configure them differently; in general the package assumes it's an addition to the system, unless told otherwise. (Additionally I'd say that binaries installed to /bin that require libraries installed to /usr is a bug, but something that should be dealt with separately. Though with the direction people seem to think is needed, I'm not sure how much effort anyone will put into that.) [1] http://forums.gentoo.org/viewtopic-p-6866484.html -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 6:43 PM, Rich Freeman wrote: > On Wed, Jan 4, 2012 at 7:58 AM, Arun Raghavan wrote: >> Does mdev support all the rules we have in /lib/udev/rules.d/? The >> Internet is surprisingly mute on this subject, but a quick grep >> through the busybox source doesn't turn up anything that suggests that >> it might. > > I think the main use case for mdev is to do a one-time creation of > typical device nodes with minimal use of resources. In that case, you don't need a userspace daemon at all. Just use devtmpfs. That'll use even lower resources. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 7:58 AM, Arun Raghavan wrote: > Does mdev support all the rules we have in /lib/udev/rules.d/? The > Internet is surprisingly mute on this subject, but a quick grep > through the busybox source doesn't turn up anything that suggests that > it might. I think the main use case for mdev is to do a one-time creation of typical device nodes with minimal use of resources. Perhaps you might say mdev is to udev as dash is to bash (though dash is syntax-compatible with bash, or at least it aims to be, and I'm not sure the same is true of mdev vs udev). If you're running a server or embedded device and you just need it to detect your hard drives and maybe a few devices you're willing to write scripts for, then it is a perfect choice. I have no idea how well it supports hotplugging of usb devices and such. For a desktop - it seems like a poor choice. By the time you enhanced it to do everything udev does you'll ruin it for embedded use and probably be stuck with all the same issues we have with udev. Fork udev if you must (good luck with that), but I don't really see mdev as being a real competitor. By all means write up an mdev howto and link it in the embedded guide or if enough users are passionate about it perhaps even link it in the handbook (as an alternative for adventurous users with special needs). However, I just can't see it ever becoming the default on a general-purpose distro like Gentoo (which aims to be all things to all people as much as is supportable). Certainly it is in the spirit of Gentoo to support it as an option for those willing to deal with the downsides (don't expect your bluetooth keyboard to work automagically, etc). Rich
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On 3 January 2012 15:21, Walter Dnes wrote: > On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote > >> I see three options: >> >> 1) Start migrating packages along with upstream and have everyone who >> has a separate /usr (including me by the way) start using an initramfs >> of some kind, either dracut or one that we generate specifically for >> gentoo. The reason I suggest the initramfs, is, unfortunately if we >> migrate everything, nothing else would work. >> >> 2) Combine the sbin and bin directories both on the root >> filesystem and in /usr by moving things from /sbin to /bin and /usr/sbin >> to /usr/bin. >> >> 3) Try to maintain things the way they are as long as possible. > > 4) Following pointers from Zac Medico and others, I've managed to get > Gentoo running with busybox's mdev, instead of udev. See > http://archives.gentoo.org/gentoo-user/msg_bc91b392ee0f76376104591cdf7dc5f0.xml > Executive summary... look Ma; no udev! Does mdev support all the rules we have in /lib/udev/rules.d/? The Internet is surprisingly mute on this subject, but a quick grep through the busybox source doesn't turn up anything that suggests that it might. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Michał Górny schrieb: > On Wed, 04 Jan 2012 01:47:38 +0100 > Thomas Sachau wrote: > >> 2. switching from udev to mdev (avoids required /usr of udev) >> 3. some wrapper script to mount /usr before udev starts > > These two should be really discouraged as a cheap, temporary solution. > We should not support hate-admining. I personally think that busybox is > ready to go into /usr even earlier than udev. Please give us a bit more than just your opinion. Why do you see mdev as a temporary solution? And this part was not about the movement to /usr at all, so why do you suggest another movement here? And while you answer that, please also tell us, why you want to migrate packages to a different install location without a need. > >> For the idea of complete migration to /usr, i see no reason to go this >> route in advance. Just keep with our default install locations and >> follow upstream, if and where needed. > > What about upstreams who do not care? In other words, all those > packages which we hack to install into rootfs? They install and work fine, so just keep it this way. I did not see any argument to move packages around, that work well and have no issue with their current install location. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Exorcising a d(a)emon from GNOME's past (aka EsounD Last Rites)
El mié, 04-01-2012 a las 09:12 +0530, Arun Raghavan escribió: > On 4 January 2012 06:48, Nirbheek Chauhan wrote: > > Hi folks, > > > > Today, I was shocked to find that the EsounD daemon is still in the > > tree and new ebuilds are actually still pulling it in under USE=esd! > > > > Proposal: package.mask media-sound/esound, use.mask USE=esd. Anything > > that still uses it should stop using it. Anything that /needs it/ > > should be purged from the tree with extreme prejudice[1]. > > > > I'll do the first two today, and the rest of the rituals necessary to > > complete the exorcism will take a month. Help in this regard is > > welcome since the job is rather straightforward. > > > > Thanks! > > > > 1. In exceptional cases, a dependency on pulseaudio will also suffice > > since pulseaudio emulates an esound socket while running with > > `module-protocol-esound-unix` loaded, which is the default. > > We've just made it optional in upstream git as well, so unless someone > screams murder, I'm going to make esd support an off-by-default USE > flag for media-sound/pulseaudio as well. > \o/ Hope that will help to not hit bug 241386 in "common" setups that shouldn't require esd plugin :D signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last Rites of dev-java/jrockit-jdk-bin
# Ralph Sennhauser (04 Jan 2012) # Outdated Java version, fails to fetch, no upstream. #228929 # Removal in 30 days. dev-java/jrockit-jdk-bin
[gentoo-dev] Re: rfc: locations of binaries and separate /usr
The 03/01/12, G.Wolfe Woodbury wrote: > The problem is that one group of developers is ignoring years of history > and purpose in the separation of /bin and /usr/bin and the ability of > having a separate /usr. This is in the udev development team and they > /deliberately/ placed or used some programs in /usr/bin instead /bin and > requiring that /usr bee in the root partition. The udev team has nothing to do with the /usr mount requirement. Lot of packages hooked themselves via udev while they had binaries or dependencies in /usr. > I will note that the historical separation of the /usr stems from the > days of user home directories being in /usr/home instead of /home. It > is getting to the point that the security aspects of having a read-only > mount for userspace executables is being overridden by developer fiat. It's a joke? -- Nicolas Sebrecht
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 04 Jan 2012 01:47:38 +0100 Thomas Sachau wrote: > 2. switching from udev to mdev (avoids required /usr of udev) > 3. some wrapper script to mount /usr before udev starts These two should be really discouraged as a cheap, temporary solution. We should not support hate-admining. I personally think that busybox is ready to go into /usr even earlier than udev. > For the idea of complete migration to /usr, i see no reason to go this > route in advance. Just keep with our default install locations and > follow upstream, if and where needed. What about upstreams who do not care? In other words, all those packages which we hack to install into rootfs? -- Best regards, Michał Górny signature.asc Description: PGP signature
