Mailing List Archive

On Wed, 4 Jan 2012 16:51:12 +0100
Michał Górny <mgorny@gentoo.org> 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

On Wed, 4 Jan 2012 15:54:07 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 4 Jan 2012 16:51:12 +0100
> Michał Górny <mgorny@gentoo.org> 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

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

On Wed, 4 Jan 2012 17:33:15 +0100
Fabian Groffen <grobian@gentoo.org> 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

>>>>> 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

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
tester@gentoo.org
Gentoo Developer

On Wed, 2012-01-04 at 15:54 +0000, Ciaran McCreesh wrote:
> On Wed, 4 Jan 2012 16:51:12 +0100
> Michał Górny <mgorny@gentoo.org> 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
tester@gentoo.org
Gentoo Developer

On Wed, 04 Jan 2012 12:40:10 -0500
Olivier Crête <tester@gentoo.org> wrote:
> On Wed, 2012-01-04 at 15:54 +0000, Ciaran McCreesh wrote:
> > On Wed, 4 Jan 2012 16:51:12 +0100
> > Michał Górny <mgorny@gentoo.org> 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

On Wed, Jan 04, 2012 at 03:19:57PM +0000, 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 : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

* 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

2012/1/5 Ulrich Mueller <ulm@gentoo.org>
>
>>
> 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 );"

* Olivier Crête schrieb am 04.01.12 um 18:40 Uhr:
> On Wed, 2012-01-04 at 15:54 +0000, Ciaran McCreesh wrote:
> > On Wed, 4 Jan 2012 16:51:12 +0100
> > Michał Górny <mgorny@gentoo.org> 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

On Thu, 5 Jan 2012 07:27:49 +1300
Kent Fredric <kentfredric@gmail.com> wrote:

> 2012/1/5 Ulrich Mueller <ulm@gentoo.org>
> >
> >>
> > 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

Michał Górny schrieb:
> On Wed, 04 Jan 2012 13:06:11 +0100
> Thomas Sachau <tommy@gentoo.org> wrote:
>
>> Michał Górny schrieb:
>>> On Wed, 04 Jan 2012 01:47:38 +0100
>>> Thomas Sachau <tommy@gentoo.org> 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

On Wed, 4 Jan 2012 18:12:18 +0100
Ulrich Mueller <ulm@gentoo.org> 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

On Thu, 2012-01-05 at 07:27 +1300, Kent Fredric wrote:
> 2012/1/5 Ulrich Mueller <ulm@gentoo.org>
> >
> >>
> > 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
tester@gentoo.org
Gentoo Developer

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 +0000, Ciaran McCreesh wrote:
> > > On Wed, 4 Jan 2012 16:51:12 +0100
> > > Michał Górny <mgorny@gentoo.org> 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
tester@gentoo.org
Gentoo Developer

On Wed, Jan 4, 2012 at 1:27 PM, Kent Fredric <kentfredric@gmail.com> 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

On 04-01-2012 19:50:24 +0100, Michał Górny wrote:
> On Wed, 4 Jan 2012 18:12:18 +0100
> Ulrich Mueller <ulm@gentoo.org> 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

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

On Wed, 04 Jan 2012 19:48:03 +0100
Thomas Sachau <tommy@gentoo.org> 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

On Wed, 4 Jan 2012 20:00:51 +0100
Fabian Groffen <grobian@gentoo.org> wrote:

> On 04-01-2012 19:50:24 +0100, Michał Górny wrote:
> > On Wed, 4 Jan 2012 18:12:18 +0100
> > Ulrich Mueller <ulm@gentoo.org> 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

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

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

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 <eras@gentoo.org>