Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Eray Aslan]

On 2012-01-01 11:50 PM, Olivier Crête wrote:
> systemd/dracut/etc handles /usr on its own filesystem just fine. What is
> required is that /usr must be mounted before the pivot_root away from
> the initramfs.

Nitpick:  I don't think pivot_root is used anymore.  It is basically
unlink, mount, chroot and exec now (i.e. switch_root).

RedHat made some bad design decisions on RPM (.rpmnew files anyone?) and
udev.  Udev was probably salvagable before systemd but noone has the
motivation or the man-power to manage the huge delta that would result
now.  It would probably amount to forking udev.  So people are following
along even if they are unhappy.

Plus Redhat did not support in-place upgrades last time I checked.  So
they don't really care for a lot of problems that are important for us.

Regarding the original question, I belive there are 2 issues here:
1. Requiring initramfs (or dracut or whatever) for separate /usr
2. Migrating /bin to /usr/bin, /sbin to /usr/sbin etc.

For the first point, we should start requiring initramfs of some sort
for separate /usr now.  That train has passed.

For the second point, we should hold on as long as we deem appropriate.
Then reconsider and -most probably- move ahead with the migration.  Main
point is not to break existing installations by making the move too
quickly.  Give sysadmins time to to adjust, resize partitions if
necessary etc.  Do not go for half way solutions (i.e. number 2 in the
original email).

As a side note, thank you and keep up your good work on OpenRC.  I find
it is easier, cleaner and in general superior to systemd especially in
server settings.  And for my laptop, I don't really care which init
system is used anyway.

-- 
Eray Aslan 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Michał Górny]

On Mon, 2 Jan 2012 13:24:00 +0700
Nguyen Thai Ngoc Duy  wrote:

> On Sun, Jan 1, 2012 at 8:59 AM, William Hubbs 
> wrote:
> > Udev, kmod (which is a replacement for module-init-tools which will
> > be needed by >=udev-176), systemd, and soon others, are advocating
> > a major change to the locations where binaries and libraries are
> > stored on linux systems.
> 
> Could you please point me to the discussions where udev, kmod and soon
> others are advocating /usr/bin and /bin unification?

I think he meant 'kmod doesn't provide hacks necessary to installs to
two roots at once'.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Sven Vermeulen]

On Sun, Jan 01, 2012 at 03:21:47PM -0500, Olivier Crête wrote:
> > But if people really want to focus on initramfs, I'd appreciate some
> > documentation help on it. Not only on how to create one, but also why it is
> > necessary, how to manage initramfs'es, the concepts underlying, etc.
> 
> Short version: use dracut.

And how does dracut know which files it needs to mount my /usr? 

Wkr,
Sven Vermeulen

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Rich Freeman]

On Mon, Jan 2, 2012 at 6:47 AM, Sven Vermeulen  wrote:
> And how does dracut know which files it needs to mount my /usr?

I assume based on the selection of modules that you enabled when
building/running it.

I believe dracut builds static binaries, so it mainly needs updating
when you build a new kernel.

Of course, right now dracut won't mount your /usr in any case, so it
needs to be improved.

Rich

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Kent Fredric]

On 3 January 2012 01:58, Rich Freeman  wrote:

> On Mon, Jan 2, 2012 at 6:47 AM, Sven Vermeulen  wrote:
> > And how does dracut know which files it needs to mount my /usr?
>
> I assume based on the selection of modules that you enabled when
> building/running it.
>
> I believe dracut builds static binaries, so it mainly needs updating
> when you build a new kernel.
>
>
It also takes a list of filesystem types to add support for mounting , and
copies the mount.* binaries across to the tmpfs root image, along with any
dependencies.

May help to understand if you see the listing of the cpio'd archive:
https://gist.github.com/1550652

Its sort of magical really.

You'll note its only got a smattering of console fonts, particularly
"usr/share/consolefonts/ter-112n.psf", which I'm not even sure how it works
out.

The only place I have that configured is /etc/conf.d/consolefont and it
somehow works it out.

You may also notice a non-standard 'v86d' in sbin/  , for uvesafb support.

Its added by a simple dracut module I whipped up in 10 minutes, and its far
simpler to do with dracut  than it ever was with genkernel.

/usr/share/dracut/modules.d/95v86d/module-setup.sh

#!/bin/bash
# -*- mode: shell-script; indent-tabs-mode: nil; sh-basic-offset: 4; -*-
# ex: ts=8 sw=4 sts=4 et filetype=sh

check() {
return 0
}

depends() {
return 0
}

install() {
local _d

dracut_install "/sbin/v86d"
}


Been using dracut for 2+ months now and love it.

Sure, I've had to re-implement the bits of genkernel I actually used , and
I still lack an "add it to grub.conf for me" option, but its still overall
a net improvement in my eyes. ( I only ever really used genkernel to
automate compile and initrd creation, all the things that would touch the
.config file I disabled )

Here is basically what I run after I have my .config ready:

https://gist.github.com/1550685


-- 
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] Six month major project on Gentoo

[Paweł Hajdan, Jr.]

On 12/19/11 7:14 PM, Sébastien Fabbro wrote:
> One project that could be very useful for Gentoo is an automated
> stabilization/testing for ebuilds. Obviously it will require some work
> from the ebuild maintainers, but the ability to distribute the
> stabilization recipes across a volunteering Gentoo community via
> something like BOINC could be worth looking at.

I can help with guidance and mentoring here.

I'm maintaining a set of scripts

that I use for mass-stabilization and related tasks. If someone wants to
extend it so the testing can be distributed, that's great.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr

[William Hubbs]

On Mon, Jan 02, 2012 at 05:39:39AM +, Duncan wrote:
> Olivier Crête posted on Sun, 01 Jan 2012 15:17:50 -0500 as excerpted:
> 
> > On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
> >> I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
> >> deleted.
> >> 
> >> However, what I would like to see is that the package maintainers would
> >> be responsible for creating any compatibility symlinks their package
> >> needs, not portage. I don't think it is a good idea to have portage or
> >> any package manager controling the migration.
> > 
> > The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
> > then create symlinks from the other dirs to /usr/bin.. That can be done
> > in big move, it's the way Fedora is going to do it.
> 
> That's what I had in mind, and in fact have already been thinking about 
> trying, here.
> 
> Which is why I don't really like the idea of packages placing symlinks, 
> since then it'd likely be the symlink copied last, overwriting the actual 
> binary with the symlink... pointing at itself due to the symlinked dirs!

If we don't use symlinks at all, we do not have to
force everything in one big move like this, just allow the
package maintainers to update things as new releases come out or do rev
bumps to move their packages. Eventually everything will be off of
/{bin,sbin,lib} and be installed in /usr.

William


pgp9zNKanRc18.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Michał Górny]

On Mon, 2 Jan 2012 07:58:00 -0500
Rich Freeman  wrote:

> On Mon, Jan 2, 2012 at 6:47 AM, Sven Vermeulen 
> wrote:
> > And how does dracut know which files it needs to mount my /usr?
> 
> I assume based on the selection of modules that you enabled when
> building/running it.
> 
> I believe dracut builds static binaries, so it mainly needs updating
> when you build a new kernel.

AFAIK dracut doesn't build anything. It just copies files from
the running system.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[William Hubbs]

On Mon, Jan 02, 2012 at 01:24:00PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Sun, Jan 1, 2012 at 8:59 AM, William Hubbs  wrote:
> > Udev, kmod (which is a replacement for module-init-tools which will be 
> > needed
> > by >=udev-176), systemd, and soon others, are advocating a major change
> > to the locations where binaries and libraries are stored on linux
> > systems.
> 
> Could you please point me to the discussions where udev, kmod and soon
> others are advocating /usr/bin and /bin unification?

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
http://fedoraproject.org/wiki/Features/UsrMove

Also udev git now installs by default in /usr/bin and kmod installs
by default in /usr/bin.

Udev has now also been changed so that it doesn't care if rules fail to
run if/usr is not mounted. It doesn't keep track of this type of failure
and doesn't give us a way to re-run these rules.

That is just the beginning; I'm sure more packages will be changed to
follow this setup.

William



pgpW7E1CcbTeg.pgp
Description: PGP signature

Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr

[Alexis Ballier]

On Sun, 1 Jan 2012 00:16:29 -0600
Ryan Hill  wrote:

> On Sat, 31 Dec 2011 19:59:47 -0600
> William Hubbs  wrote:
> 
> > Udev, kmod (which is a replacement for module-init-tools which will
> > be needed by >=udev-176), systemd, and soon others, are advocating
> > a major change to the locations where binaries and libraries are
> > stored on linux systems.
> > 
> > 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 coulda swore April was another four months away...
> 
> 

no, in April they will declare the zillions of #!/bin/sh scripts
broken because they rely on a so old unix standard :=)

A.

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[William Hubbs]

On Sun, Jan 01, 2012 at 06:54:34PM +0100, Michał Górny wrote:
> On Sat, 31 Dec 2011 19:59:47 -0600
> We should *at least* start doing some preparations, like ensuring that
> random things don't unnecessarily hardcode /sbin or /bin paths. Most
> importantly, if a particular tool runs in a complete environment (which
> is true for most of the cases), there is no need to hardcode paths to
> tools.
> 
> As I see it, 2) seems achievable within a reasonable time now. It
> shouldn't require any specific changes from users (except for fixing
> their own broken scripts) yet some tree-wide action of fixing hardcoded
> paths.
> 
> We could create /sbin and /usr/sbin symlinks as well but that shouldn't
> be really necessary, especially if we prepare packages well beforehand.
> Introducing such symlinks would be hard to perform and getting rid of
> them later would be even harder; mostly due to PMS-enforced limitations.

I'm not really a fan of the compatibility symlinks either the more I
think about it. I think that basically packages can revbump to make this
migration happen, or in the case of udev and kmod and other upstreams
that support it, not hard code the configuration.

> 
> For a long-term view, 1) is the only way to go. Splitting packages
> randomly between rootfs and /usr was never really correct, and we
> especially shouldn't force users to junk their systems with shattered
> packages and cheap glue to keep it all working.
> 
> I'd suggest going the other way than I did with kmod. Temporary IUSE
> like 'install-to-usr', disabled by default for now. Packages having
> that IUSE should have correct USE-dependencies, and users who need not
> to use that could just enable 'install-to-usr' globally (we'd probably
> want to mask it first).

I'm not sure that a use flag is a good idea for this, because there will
definitely be people who would turn it off, and with upstreams assuming
that this is how things are installed, those who turn it off will have
broken systems.

Here is My thought about how we can make this transition happen:

* Right now, I can re-work our kmod ebuild to install to its default
  locations in /usr.

* When udev 176 is released, I'll put it in the tree, masked, installing
  to its default locations. I can actually rework the live ebuild right
  now to do this.

* I will then open a tracker for issues that will need to be fixed
  before we can unmask it.

* Next, we will need people to unmask udev-176 and test to find issues.
  I will definitely be one of these since I have separate
  /usr on my desktop, however, I can't test all possible
  configurations/packages here, so the more the merrier.

* We also need to get a better understanding of dracut at this point. I
  believe that making an initramfs is as simple as running:
  dracut "" -H
  as root. Then you have to add it to your boot loader. The one thing I
  haven't figured  out yet is whether it is possible to create an
  initramfs that doesn't have to be updated with every kernel upgrade.

* Once the issues are ironed out we unmask udev-176 and go from there.

What does everyone think? What am I leaving out?

William



pgpzSQ6FeBDNh.pgp
Description: PGP signature

Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr

[Michał Górny]

On Mon, 2 Jan 2012 14:54:39 -0300
Alexis Ballier  wrote:

> On Sun, 1 Jan 2012 00:16:29 -0600
> Ryan Hill  wrote:
> 
> > On Sat, 31 Dec 2011 19:59:47 -0600
> > William Hubbs  wrote:
> > 
> > > Udev, kmod (which is a replacement for module-init-tools which
> > > will be needed by >=udev-176), systemd, and soon others, are
> > > advocating a major change to the locations where binaries and
> > > libraries are stored on linux systems.
> > > 
> > > 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 coulda swore April was another four months away...
> 
> no, in April they will declare the zillions of #!/bin/sh scripts
> broken because they rely on a so old unix standard :=)

Yes, we should migrate to #!/usr/bin/env sh :P.


-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Michał Górny]

On Mon, 2 Jan 2012 11:54:57 -0600
William Hubbs  wrote:

> > For a long-term view, 1) is the only way to go. Splitting packages
> > randomly between rootfs and /usr was never really correct, and we
> > especially shouldn't force users to junk their systems with
> > shattered packages and cheap glue to keep it all working.
> > 
> > I'd suggest going the other way than I did with kmod. Temporary IUSE
> > like 'install-to-usr', disabled by default for now. Packages having
> > that IUSE should have correct USE-dependencies, and users who need
> > not to use that could just enable 'install-to-usr' globally (we'd
> > probably want to mask it first).
> 
> I'm not sure that a use flag is a good idea for this, because there
> will definitely be people who would turn it off, and with upstreams
> assuming that this is how things are installed, those who turn it off
> will have broken systems.

But it will give some of us a chance to carefully test changes without
enforcing them on all users or leaving them to lag behind with
packages.

Another, maybe even better solution is keeping modded packages in an
overlay.

> What does everyone think? What am I leaving out?

I think you are missing the long, necessary transition period.

Also, I don't think we should move udev (or anything else to /usr)
before we move all of its deps there. Well, at least library-level deps
which would be systemd. But I think I'll need to move it there anyway
because we don't have libdbus in rootfs.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Michał Górny]

On Sun, 1 Jan 2012 14:39:57 +0530
Nirbheek Chauhan  wrote:

> On Sun, Jan 1, 2012 at 2:23 PM, 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.
> 
> Actually, I've always thought that the split between /usr/bin and /bin
> was quite arbitrary. However, I would like to note that merging /bin
> and /usr/bin would break some app combinations like bzip2+pbzip2, so
> that problem also needs to be solved (via eselect perhaps).

Well, that /usr/bin idea of mine was quite hacky anyway. I don't think
we should even consider it here.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[Michał Górny]

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.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: locations of binaries and separate /usr

[William Hubbs]

On Mon, Jan 02, 2012 at 07:37:41PM +0100, Michał Górny wrote:
> On Mon, 2 Jan 2012 11:54:57 -0600
> William Hubbs  wrote:
> 
> > > For a long-term view, 1) is the only way to go. Splitting packages
> > > randomly between rootfs and /usr was never really correct, and we
> > > especially shouldn't force users to junk their systems with
> > > shattered packages and cheap glue to keep it all working.
> > > 
> > > I'd suggest going the other way than I did with kmod. Temporary IUSE
> > > like 'install-to-usr', disabled by default for now. Packages having
> > > that IUSE should have correct USE-dependencies, and users who need
> > > not to use that could just enable 'install-to-usr' globally (we'd
> > > probably want to mask it first).
> > 
> > I'm not sure that a use flag is a good idea for this, because there
> > will definitely be people who would turn it off, and with upstreams
> > assuming that this is how things are installed, those who turn it off
> > will have broken systems.
> 
> But it will give some of us a chance to carefully test changes without
> enforcing them on all users or leaving them to lag behind with
> packages.

Stable or ~arch users wouldn't be affected, just those unmasking things
in p.mask.

> Another, maybe even better solution is keeping modded packages in an
> overlay.

Absolutely not. I don't see a reason to use an overlay for this; that's
what p.mask is for.

> > What does everyone think? What am I leaving out?
> 
> I think you are missing the long, necessary transition period.

I'm not sure I agree. I don't see why there has to be a long transition
period if we coordinate everything correctly.

William



pgpv3gxwSKmIz.pgp
Description: PGP signature

[gentoo-dev] Large ChangeLogs now split

[Andreas K. Huettel]

Hiya everyone, 

just for your information, as discussed and agreed some time ago [*], all 
ChangeLog files in gentoo-x86 have now been manually split following an 
algorithm similar to logrotate (size 100K, yearly). For details see the thread 
linked below.

Cheers, Andreas

[*] http://archives.gentoo.org/gentoo-
dev/msg_c3436497e445eaf86deea08772e5.xml

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde, sci, tex, arm, printing
dilfri...@gentoo.org
http://www.akhuettel.de/


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/transmission: ChangeLog transmission-2.41.ebuild

[Samuli Suominen]

On 01/02/2012 11:41 PM, Tomas Chvatal (scarabeus) wrote:

scarabeus12/01/02 21:41:29

   Modified: ChangeLog transmission-2.41.ebuild
   Log:
   Make it build on my system - add intltool/gettext to hard deps, fixes bug 
#379887. Reorder deps alphabetically. Depend on any ssl provided by curl.

   (Portage version: 2.2.0_alpha84/cvs/Linux x86_64)
-   emake DESTDIR="${D}" install
+   default

dodoc AUTHORS NEWS qt/README.txt
rm -f "${ED}"/usr/share/${PN}/web/LICENSE


fail.   `default` is handling DOCS as well so this isn't right.