Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 04:49, Rich Freeman wrote:
> 1. As you point out, its not a package.  That means it works
> differently than everything else, and it can't be used as a
> dependency/etc.
> 2. Genkernel's initramfs isn't all that great.  Don't get me wrong -
> it was very good back when it was new.  However, I find it hard to
> compare it to the likes of dracut.
>
> However, if it were all that serious of an issue somebody would have
> fixed it by now.  Manually building a kernel and using dracut is easy
> enough, and of course some prefer to not use an initramfs if their
> configuration allows it.
>
I haven't dared explore dracut because last I heard it was still
experimental. That people are actively using it (presumably in
production and not just experimental/development suggests at the very
least that the appropriate Gentoo wiki article needs updating (no
surprise there!).

Perhaps indeed genkernel needs some updating. When I last looked at the
best means of creating an initramfs, it was the least of the evils, but
there did seem a genuine lack of tools to accomplish it, which is where
I assume dracut came about.

Fundamentally, acknowledging a tangent of the original thread, I'd say
the jury remains out on whether Gentoo should be forcing the need of an
initramfs/rd on its users by default anyway. That kind of thing,
however, is of course, subject to a Council ruling if appropriate :) .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 11:28 PM, M. J. Everitt  wrote:
> Ok I'm gonna push the Big Red Button here, and assume you may not have
> met 'genkernel' ..

Genkernel has been around for a LONG time.  I'm well aware of it.

> ok its not a package, but its the nearest thing to
> Gentoo's solution to what you're suggesting ... And it's in the Handbook
> .. so, where's the issue, again?!

1. As you point out, its not a package.  That means it works
differently than everything else, and it can't be used as a
dependency/etc.
2. Genkernel's initramfs isn't all that great.  Don't get me wrong -
it was very good back when it was new.  However, I find it hard to
compare it to the likes of dracut.

However, if it were all that serious of an issue somebody would have
fixed it by now.  Manually building a kernel and using dracut is easy
enough, and of course some prefer to not use an initramfs if their
configuration allows it.

-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 04:08, Rich Freeman wrote:
> I think the bigger issue with the kernel is the huge configuration
> space it has.  Chromium may have a ton of USE flags compared to most
> packages, but those pale in comparison to the kernel.  Obviously it
> would not make sense to try to create a USE flag for every
> configuration option.  Now, a package that built and installed a
> kernel might have a few USE flags.  For example, it might have flags
> equivalent to the gentoo config add-ons (for openrc/systemd, and so
> on).  It might also have flags that give it some default
> configuration, or an all-modules configuration, or an all-builtin
> configuration.  I imagine that most distros ship something close to an
> all-modules config.
>
> In any case, that isn't really any kind of policy issue.  For whatever
> reason nobody has bothered to create a package.  Certainly nobody
> would object to somebody adding a new kernel package that builds and
> installs a fully configured kernel.  It might even become the
> recommended default in the kernel (without getting rid of the other
> options).
>
Ok I'm gonna push the Big Red Button here, and assume you may not have
met 'genkernel' .. ok its not a package, but its the nearest thing to
Gentoo's solution to what you're suggesting ... And it's in the Handbook
.. so, where's the issue, again?!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 10:17 PM, M. J. Everitt  wrote:
> I take your point, but I would argue that the kernel and boot subsystem
> really are special cases .. you don't go hacking around the chromium
> sources to fundamentally alter the way/order it works, right?! Likewise,
> if you don't like chromium, you might install firefox .. cf. say, Lilo
> and grub. It is the flexibility (and, I concede, the complexity, and
> hence 'power') that defines Gentoo here.
>

I think the bigger issue with the kernel is the huge configuration
space it has.  Chromium may have a ton of USE flags compared to most
packages, but those pale in comparison to the kernel.  Obviously it
would not make sense to try to create a USE flag for every
configuration option.  Now, a package that built and installed a
kernel might have a few USE flags.  For example, it might have flags
equivalent to the gentoo config add-ons (for openrc/systemd, and so
on).  It might also have flags that give it some default
configuration, or an all-modules configuration, or an all-builtin
configuration.  I imagine that most distros ship something close to an
all-modules config.

In any case, that isn't really any kind of policy issue.  For whatever
reason nobody has bothered to create a package.  Certainly nobody
would object to somebody adding a new kernel package that builds and
installs a fully configured kernel.  It might even become the
recommended default in the kernel (without getting rid of the other
options).

-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 03:06, Rich Freeman wrote:
>
> By that argument, when you run emerge chromium shouldn't it just dump
> the chromium sources in /usr/src, so that you can build and install
> your own chromium?
>
> The whole point of a source-based package manager is that it actually
> BUILDs the packages.  Why do we treat the kernel differently from
> every single other package?
>
> I get that users often want to build their own, and that is fine.  We
> SHOULD have a package that dumps sources in /usr/src (though to be
> honest I prefer to just fetch mine using git).  However, why shouldn't
> emerge virtual/kernel not just give you a /boot/vmlinux-x.y.z the same
> way that emerge vim gives you a /usr/bin/vim?
>
I take your point, but I would argue that the kernel and boot subsystem
really are special cases .. you don't go hacking around the chromium
sources to fundamentally alter the way/order it works, right?! Likewise,
if you don't like chromium, you might install firefox .. cf. say, Lilo
and grub. It is the flexibility (and, I concede, the complexity, and
hence 'power') that defines Gentoo here.

This also applies to the whole /usr debate .. and yes, I agree there are
caveats with both our existing setup and many of the others discussed on
this thread. I think there is a debate to be had, and whilst it has born
the inevitable bike-shedding, I think there could be some merit in a
'flattened' system. I suppose the natural follow-on question from this,
is "how best to achieve it?".



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 9:35 PM, M. J. Everitt  wrote:
> I think that is the potential for a stage4-style install. I think
> previous list discussions have maintained that the flexibility of gentoo
> is maintained by having a very basic install image, and a stage3 to
> bootstrap into, and have the user compile their own kernel.
>
> Otherwise, go install debian/ubuntu/choose-your-own-ready-boxed-linux
> ... gentoo isn't that kinda distro. Imho.

By that argument, when you run emerge chromium shouldn't it just dump
the chromium sources in /usr/src, so that you can build and install
your own chromium?

The whole point of a source-based package manager is that it actually
BUILDs the packages.  Why do we treat the kernel differently from
every single other package?

I get that users often want to build their own, and that is fine.  We
SHOULD have a package that dumps sources in /usr/src (though to be
honest I prefer to just fetch mine using git).  However, why shouldn't
emerge virtual/kernel not just give you a /boot/vmlinux-x.y.z the same
way that emerge vim gives you a /usr/bin/vim?


-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 02:14, Rich Freeman wrote:
> Part of me also wonders if Gentoo would be better off having emerge
> gentoo-sources actually BUILD the kernel and initramfs and not just
> dump a bunch of sources on the disk.  Most distros consider an
> initramfs a no-brainer because it just ships already setup, and an
> initramfs is a lot more forgiving when you add a new drive and your
> firmware/kernel decides to re-number everything.  Just label your
> filesystems or store UUIDs and the initramfs will figure out what
> happened.
>
I think that is the potential for a stage4-style install. I think
previous list discussions have maintained that the flexibility of gentoo
is maintained by having a very basic install image, and a stage3 to
bootstrap into, and have the user compile their own kernel.

Otherwise, go install debian/ubuntu/choose-your-own-ready-boxed-linux
... gentoo isn't that kinda distro. Imho.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 8:37 PM, M. J. Everitt  wrote:
> I may have contributed to the latter point, but addressing the former
> specifically, I, like others, have /usr mounted on an NFS server for
> thin clients (not in the full-true sense, but with a very minimal /
> currently residing on USB).
> What you propose moving binaries from / to /usr would render them
> completely unbootable without early mounting via initramfs.

I believe dracut will auto-mount /usr.  As long as your fstab is
accurate (double-check - sometimes people don't have correct settings
for root since without something like dracut the root filesystem isn't
mounted according to fstab), I suspect it will just NFS-mount your
/usr before pivoting.  If not you can probably use the fstab-user
module to force it to mount (you stick a second dracut-specific fstab
file in /etc and it will mount everything it finds in there whether it
thinks it needs it or not).  I'd start with the auto-magic detection
since it tends to work.

Dracut needs a root= setting on the kernel command line to get it
started, but once it finds that it tends to figure out how to get it
mounted read-only, then it looks inside for an /etc/fstab to figure
out the rest.  When you build the initramfs dracut will also copy
files like mdadm.conf into the initramfs automatically.  You can also
configure it to load extra stuff in there (my initramfs doubles as a
rescue image, so I stick a few convenience things in there that
strictly aren't needed, like btrfstune and a full bash instead of just
dash).

Part of me also wonders if Gentoo would be better off having emerge
gentoo-sources actually BUILD the kernel and initramfs and not just
dump a bunch of sources on the disk.  Most distros consider an
initramfs a no-brainer because it just ships already setup, and an
initramfs is a lot more forgiving when you add a new drive and your
firmware/kernel decides to re-number everything.  Just label your
filesystems or store UUIDs and the initramfs will figure out what
happened.

-- 
Rich

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 8:09 PM, J. Roeleveld  wrote:
>
> I actually write my own initramfs because neither dracut not genkernel end up
> with a convenient boot system.
>
> I have 2 disks, both encrypted.
> I prefer only to enter the decryption password once. Both Dracut and Genkernel
> insist on asking for the password/key for every single disk.
>

You can of course roll your own, but I imagine that it would be more
straightforward to just write your own dracut plugin.  They're
basically just scripts that run at whatever boot stage you define.
You might also just be able to modify the existing plugin.

-- 
Rich

Re: [gentoo-dev] usr merge

[Gordon Pettey]

On Sat, Apr 9, 2016 at 5:50 PM, Philip Webb  wrote:

> 160409 Canek Peláez Valdés wrote:
> > On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb 
> wrote:
> >> I've always used Lilo, which is simple + reliable :
> >> I never see questions re it here, but there are many re Grub.
> >> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> >> When setting it up, I suppressed UEFI in the BIOS settings :
> >> isn't that what anyone not running M$ would do ?
> > I just disabled secure boot, although it's possible to use it with Linux.
> > However, it would require to manually sign everything from boot loader
> > to kernel modules, since Gentoo has no infrastructure to do that.
> > I don't "supress" UEFI, since it's *obviously* so much better than BIOS
> > and since bootctl (the program formerly known as gummiboot)
> > it's incredible easy to use. You don't even notice it's there.
>
> Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.


If you have "secure boot", you have UEFI. You can't have it without.

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 00:53, William Hubbs wrote:
>
> The original discussion was about the usr merge [1], which is taking the
> binary parts of / and putting them in /usr, then inserting symlinks in /
> to preserve backward compatibility. Yes, I'm pointing to a document on
> fdo, but the systemd guys have nothing to do with the /usr merge; it
> originally happened in Solaris.
>
> I never supported the reverse merge that has been discussed, it was just
> brought up I guess as an example of a Gentoo user being able to do his
> own setup. Reverse merge meaning moving everything from /usr to /.
>
I may have contributed to the latter point, but addressing the former
specifically, I, like others, have /usr mounted on an NFS server for
thin clients (not in the full-true sense, but with a very minimal /
currently residing on USB).
What you propose moving binaries from / to /usr would render them
completely unbootable without early mounting via initramfs. Granted,
what I have now is rather a bodge, but it's working fine, and provided I
am meticulous about any rare changes from the host build system to /,
this is a small problem in the grander scheme of things, and I have one
maintained 'install' on my build system. Ok, so a full thin-client would
probably be a better* option, but I'm running with what I got, rather
than investing a lot (of/more) time/energy in getting that solution
working, which failed on (several) previous attempts (hence *).



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Saturday, April 09, 2016 05:15:08 PM James Le Cuirot wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400
> 
> waltd...@waltdnes.org wrote:
> > > I never really got the mentality that using an initramfs is a
> > > burden.
> > > 
> >   One more piece of software that can go wrong.  You have to
> > 
> > maintain+configure it; e.g. sync software and library versions with
> > what's on the rest of the system.
> 
> Errm, have you ever actually used dracut?
> 
> dracut --kver 4.5
> 
> Wow, that was hard! It requires zero configuration and that's true even
> if you've got LVM on top of LUKS on top of RAID or something equally
> complex. If you're already running that kernel version, you don't even
> need to specify it.

I actually write my own initramfs because neither dracut not genkernel end up 
with a convenient boot system.

I have 2 disks, both encrypted.
I prefer only to enter the decryption password once. Both Dracut and Genkernel 
insist on asking for the password/key for every single disk.

The ONLY reason why I feel an initramfs is warranted is because of the 
encryption. Without that, it should not be necessary.

--
Joost

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

Re: [gentoo-dev] usr merge

[William Hubbs]

Hi Philip,

On Sat, Apr 09, 2016 at 06:50:49PM -0400, Philip Webb wrote:
> Can you or anyone else answer my other question re the origin of the thread ?
> -- ie is this a revival of not putting  /usr  on its own partition
> or is it a new proposal to alter the file system in some other way ?

The original discussion was about the usr merge [1], which is taking the
binary parts of / and putting them in /usr, then inserting symlinks in /
to preserve backward compatibility. Yes, I'm pointing to a document on
fdo, but the systemd guys have nothing to do with the /usr merge; it
originally happened in Solaris.

I never supported the reverse merge that has been discussed, it was just
brought up I guess as an example of a Gentoo user being able to do his
own setup. Reverse merge meaning moving everything from /usr to /.

The thread has definitely gotten more out of hand than I anticipated. It
is very hard at this point to separate the pros/cons, bikeshedding and
personal preferences. That's why I requested that someone assist with a
summary. :-)

William

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/


signature.asc
Description: Digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 09/04/16 23:50, Philip Webb wrote:
> 160409 Canek Peláez Valdés wrote:
>> On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb  wrote:
>>> I've always used Lilo, which is simple + reliable :
>>> I never see questions re it here, but there are many re Grub.
>>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>>> When setting it up, I suppressed UEFI in the BIOS settings :
>>> isn't that what anyone not running M$ would do ?
>> I just disabled secure boot, although it's possible to use it with Linux.
>> However, it would require to manually sign everything from boot loader
>> to kernel modules, since Gentoo has no infrastructure to do that.
>> I don't "supress" UEFI, since it's *obviously* so much better than BIOS
>> and since bootctl (the program formerly known as gummiboot)
>> it's incredible easy to use. You don't even notice it's there.
> Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.
>
>> I believe there are motherboards where you don't have the option
>> to "supress" UEFI, since they simply don't have BIOS anymore.
>> Seriously, UEFI is s much better.
> Thanks for the enlightment (smile).
>
> Can you or anyone else answer my other question re the origin of the thread ?
> -- ie is this a revival of not putting  /usr  on its own partition
> or is it a new proposal to alter the file system in some other way ?
>
Philip, the discussion was prompted from this original message by WilliamH:

https://archives.gentoo.org/gentoo-dev/message/df3c1494ea49191d4e3d442e37eb8ca2

Basically there is a desire to either (1) move /bin, /sbin to /usr/bin,
/usr/sbin or (2) the reverse (ie. eliminate /usr) for a variety of
reasons, but predominately to offer "more users more choice", and uphold
the principle of Gentoo being a distro of flexibility.

Whilst there is some good pros/cons being aired, there is also the usual
amount of gentoo bike-shedding, and personal preference distorting the
discussion :) .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Philip Webb]

160409 Canek Peláez Valdés wrote:
> On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb  wrote:
>> I've always used Lilo, which is simple + reliable :
>> I never see questions re it here, but there are many re Grub.
>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>> When setting it up, I suppressed UEFI in the BIOS settings :
>> isn't that what anyone not running M$ would do ?
> I just disabled secure boot, although it's possible to use it with Linux.
> However, it would require to manually sign everything from boot loader
> to kernel modules, since Gentoo has no infrastructure to do that.
> I don't "supress" UEFI, since it's *obviously* so much better than BIOS
> and since bootctl (the program formerly known as gummiboot)
> it's incredible easy to use. You don't even notice it's there.

Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.

> I believe there are motherboards where you don't have the option
> to "supress" UEFI, since they simply don't have BIOS anymore.
> Seriously, UEFI is s much better.

Thanks for the enlightment (smile).

Can you or anyone else answer my other question re the origin of the thread ?
-- ie is this a revival of not putting  /usr  on its own partition
or is it a new proposal to alter the file system in some other way ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] usr merge

[Canek Peláez Valdés]

On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb  wrote:
> 160409 Canek Peláez Valdés wrote:
>> You use LILO : that means, you don't use UEFI :
>> that means, almost certainly, you don't use recent hardware.
>
> I've always used Lilo, which is simple + reliable :
> I never see questions re it here, but there are many re Grub.
> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> When setting it up, I suppressed UEFI in the BIOS settings :
> isn't that what anyone not running M$ would do ?

I just disabled secure boot, although it's possible to use it with
Linux. However it would require to manually sign everything from boot
loader to kernel modules, since Gentoo has no infrastructure to do
that. Maybe a future project.

I don't "supress" UEFI, since it's *obviously* so much better than
BIOS, and since bootctl (the program formerly known as gummiboot) it's
incredible easy to use. You don't even notice it's there.

Also, I'm not sure, but I believe there are motherboards where you
don't have the option to "supress" UEFI, since they simply don't have
BIOS anymore. I could be wrong; but even if that's the case, I'm
pretty sure in the future BIOS will get relegated to a niche market,
if it doesn't completely disappear.

Seriously, UEFI is s much better.

Regards.
-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 09/04/16 20:53, Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 3:49 PM, Philip Webb  wrote:
>> I've always used Lilo, which is simple + reliable :
>> I never see questions re it here, but there are many re Grub.
>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>> When setting it up, I suppressed UEFI in the BIOS settings :
>> isn't that what anyone not running M$ would do ?
> That depends on how much you care about rootkits...  :)
>
Rootkits in linux ... why?!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 3:49 PM, Philip Webb  wrote:
> I've always used Lilo, which is simple + reliable :
> I never see questions re it here, but there are many re Grub.
> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> When setting it up, I suppressed UEFI in the BIOS settings :
> isn't that what anyone not running M$ would do ?

That depends on how much you care about rootkits...  :)

-- 
Rich

Re: [gentoo-dev] usr merge

[Philip Webb]

160409 Canek Peláez Valdés wrote:
> You use LILO : that means, you don't use UEFI :
> that means, almost certainly, you don't use recent hardware.

I've always used Lilo, which is simple + reliable :
I never see questions re it here, but there are many re Grub.
I do use recent hardware, a cutting-edge machine I built  6 mth ago .
When setting it up, I suppressed UEFI in the BIOS settings :
isn't that what anyone not running M$ would do ?
 
> Gentoo devs only are saying that if by having separated /usr
> without an initramfs, you risk screwing your system.

I haven't been reading this long thread -- merely skimming some of it -- ,
& I missed or didn't understand what is being proposed or imposed.
There was an issue earlier re not having  /use  on a separate partition
& both my machines have it on the same partition as  / .
Is this thread re that earlier matter or is it a new item ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] Re: usr merge

[Alan McKinnon]

On 09/04/2016 20:34, waltd...@waltdnes.org wrote:
> On Sat, Apr 09, 2016 at 12:18:25PM -0500, »Q« wrote
>> On Sat, 9 Apr 2016 12:09:38 -0400
>> waltd...@waltdnes.org wrote:
>>
>>> On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
>>>
 It was simply a recognition that we were already in a state where
 booting a system without /usr mounted early can cause problems.  
>>>
>>> For certain edge cases... yes.  But they were already using
>>> initramfs or merging /usr into /.  I'm talking about the 95% who
>>> don't really need it.
>>
>> Booting without /usr mounted early is something Gentoo already doesn't
>> support and can't support, right?
> 
>   If you can read this post, you've got a mighty powerful imagination.
> Because we all know that Gentoo can't boot, let alone send emails, from
> a machine with separate /usr and no initramfs... just like I'm using
> right now.
> 


That's not what he said.

He said gentoo doesn't, and can't support it, because it's a world of
pain to provide proper support to everyone who wants it. If you want it,
as you do, you get to do it yourself. While it still works, grat. When
it stops working, you fix it.

He did not say, as you imply, that it cannot work right now.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-dev] usr merge

[netfab]

Le 09/04/16 à 17:15, James Le Cuirot a tapoté :
> Errm, have you ever actually used dracut?
> 
> dracut --kver 4.5
> 
> Wow, that was hard! It requires zero configuration [...]

Sorry. Not true.

> $ emerge -pv dracut
> 
> [...]
>
> The following keyword changes are necessary to proceed:
>  (see "package.accept_keywords" in the portage(5) man page for more
> details) # required by dracut (argument)
> =sys-kernel/dracut-044 ~amd64

Re: [gentoo-dev] usr merge

[Alexis Ballier]

On Saturday, April 9, 2016 5:11:30 PM CEST, William Hubbs wrote:

...

if we don't make it optional we're going to cause some serious headaches
for people who are invested in the current status quo.
 ...


gen_usr_ldscript is only needed if you are using separate /usr without
an initramfs. This is unsupported and orthogonal to the usr merge.


just one addition: for having self-contained / with /usr on another 
partition, you just need to move libfoo.so* to /lib; the ldscript is only 
useful because the linker searches /usr/lib first then /lib, and if 
libfoo.a is in /usr/lib, it picks that one.
IOW: gen_usr_ldscript is not needed without static libs, even for the case 
you describe

[gentoo-dev] Re: usr merge

[»Q«]

On Sat, 9 Apr 2016 12:09:38 -0400
waltd...@waltdnes.org wrote:

> On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
> 
> > It was simply a recognition that we were already in a state where
> > booting a system without /usr mounted early can cause problems.  
> 
> For certain edge cases... yes.  But they were already using
> initramfs or merging /usr into /.  I'm talking about the 95% who
> don't really need it.

Booting without /usr mounted early is something Gentoo already doesn't
support and can't support, right?

Re: [gentoo-dev] usr merge

[Consus]

On 17:15 Sat 09 Apr, James Le Cuirot wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400
> waltd...@waltdnes.org wrote:
> 
> > > I never really got the mentality that using an initramfs is a
> > > burden.  
> > 
> >   One more piece of software that can go wrong.  You have to
> > maintain+configure it; e.g. sync software and library versions with
> > what's on the rest of the system.
> 
> Errm, have you ever actually used dracut?
> 
> dracut --kver 4.5
> 
> Wow, that was hard! It requires zero configuration and that's true even
> if you've got LVM on top of LUKS on top of RAID or something equally
> complex. If you're already running that kernel version, you don't even
> need to specify it.

In 2014 I switched from dracut to genkernel because after *every*
dracut's update I was writing to it's devs about a new shiny bug. Like
infinite loops in the pidof() implementation.

Re: [gentoo-dev] usr merge

[James Le Cuirot]

On Sat, 9 Apr 2016 12:09:38 -0400
waltd...@waltdnes.org wrote:

> > I never really got the mentality that using an initramfs is a
> > burden.  
> 
>   One more piece of software that can go wrong.  You have to
> maintain+configure it; e.g. sync software and library versions with
> what's on the rest of the system.

Errm, have you ever actually used dracut?

dracut --kver 4.5

Wow, that was hard! It requires zero configuration and that's true even
if you've got LVM on top of LUKS on top of RAID or something equally
complex. If you're already running that kernel version, you don't even
need to specify it.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpyPYehoZmgo.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[waltdnes]

On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote

> It was simply a recognition that we were already in a state where
> booting a system without /usr mounted early can cause problems.

  For certain edge cases... yes.  But they were already using initramfs
or merging /usr into /.  I'm talking about the 95% who don't really need
it.

> I never really got the mentality that using an initramfs is a burden.

  One more piece of software that can go wrong.  You have to
maintain+configure it; e.g. sync software and library versions with
what's on the rest of the system.

> An initramfs is just a secondary bootloader for userspace.  I almost
> always use them even if I'm just booting a VM with a single partition
> on it.  If something goes wrong you can fall back to a shell in the
> initramfs and it is like having a rescue disk built into your system
> disk.

  There is single-user mode for rescue.

> For a more complex setup it is much more robust than relying on
> the kernel to find your root, and it also lets you build with a more
> module-based kernel, which has some benefits as well even if you build
> kernels tailored to each host.

  I have "Production" and "Experimental" entries in my LILO menu.  A new
kernel is always set up as the "Experimental" entry.  After running
several days without problems, I run a script which copies the data from
the "Experimental" portion to "Production".

  The only time my system had problems "finding root" was years ago when
the switch from /dev/hd* to /dev/sd* took place.  The "Experimental"
boot with the new kernel died.  I booted "Production", read the mailing
list, changed "hd" to "sd" for the "Experimental" entry, and rebooted.
After several days without problems, I made the same change to the
"Production" entry, and copied the "Experimental" portion to
"Production".

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [PATCH v1 1/3] general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490

[Göktürk Yüksek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Andreas K. Huettel:
> On Monday 04 April 2016 06:57:51 NP-Hardass wrote:
>> On 04/04/2016 12:34 AM, Göktürk Yüksek wrote:
>>> +sufficient for adding or removing a developer. Note that 
>>> different +projects have different requirements and procedures
>>> for recruiting +developers, which may require prior
>>> arrangements to be made before +modifying the member list.
> 
>> I'm not particularly fond of this statement.  The implication is
>> that most projects require permission, whereas I believe that the
>> opposite is true.  To the best of my knowledge, most projects are
>> open, and ones that have special requirements almost always list
>> them explicitly on their project pages.
> 
> It's true that most projects are happy to accept new members, but
> usually you're expected to talk at least to some team member
> first.
> 
> (Hi I'd like to join... Sure, just add yourself!)
> 
> More of a courtesy, really... and also a good way to find out *if*
> there are any rules/restrictions.
> 
> 

My intention was to document only the mechanics involved in the
process and sidestep the permission discussion as much as possible.
Frankly, I have no experience in joining/leaving projects. I
understand that some projects are happy with people just adding
themselves without permission whereas others, like the security team,
are stricter with their requirements. Either way, the wiki will need
to be modified and possibly the alias file too. Maybe we are better
off without the last sentence, so it's less controversial?

- --
gokturk
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXCSDrAAoJEIT4AuXAiM4zTgkIAJpoyFylEAaYzpZLiBoNw/UD
AiBpbaJUtwtfgrIs11PCKORJfsJXRd4WxuNdh05NWxsmKRht1IESoE9RokCT2eQA
NbS/GUS6r7DZEifBjAtIbgykhvzWGgq4uybxUaktp9tOn+t+/zg3rvh/1316udTR
R4eXB5n9YumUrLuvVdbeQUz/bxJ1/0mKyebrKpeci+brDPjO7xpXV2xfRimZ9msP
9R2ceDzMlEYX0V1kwe/Q+Zc9fnGw+C0Z8FXZf9fgbr/bjYDL3ROPQSvjIyiVq9zF
8aCbMIS5+ZvwbkhJJ3mnChiCkH1pujMiqlgr3dqi1XdbMjL/rsphElorQt5pbSc=
=xz02
-END PGP SIGNATURE-

Re: [gentoo-dev] usr merge

[William Hubbs]

On Sat, Apr 09, 2016 at 12:06:47AM -0400, Anthony G. Basile wrote:
> On 4/8/16 11:03 PM, Rich Freeman wrote:
> > On Fri, Apr 8, 2016 at 9:51 PM, Anthony G. Basile  
> > wrote:
> >>
> >> Alternatively, this may introduce problems.  So it seems like we're
> >> fixing something that isn't broken.
> >>
> > 
> > What problems are you anticipating, especially in light of the fact
> > that many distros actually do it this way already?
> 
> RBAC policy files for one.  You'll probably break every single hardened
> gentoo server out there.
 
 Tell me more about this; I don't know a lot about what would break.
 Also, are you sure it would break, or are you just thinking that it
 would?

> scripts and programs that assume different executables with the same
> name at different points along the path, eg I know a company where
> they've set up an ssh wrapper at /usr/local/bin/ssh which wrap /usr/bin/ssh.
 
 This won't break, because /usr/bin/ssh would still exist as it does and
 /usr/local is not touched.

File colissions between the directories that are being merged would
definitely be an issue that needs to be worked out before this could
happen, and I understand that. I know of at least one, and we would need
to find out if there are others.

Forgetting about /usr/local since we don't control that, this type of
file name collision across the bin directories is not good whether or
not you merge /usr. It would cause issues in path name resolution.

> security measures where you don't dereference sym links along $PATH
> because sym links can be used in various types of exploits.
 
Every amd64 gentoo system already has one of these, the "lib" symlink,
both in / and /usr, so if you aren't dereferencing symlinks, aren't you
already broken?

> > 
> > I don't really have a problem with making it optional or the default.
> 
> if we don't make it optional we're going to cause some serious headaches
> for people who are invested in the current status quo.
> 
> > 
> > It can also be left up to the maintainers, and of course somebody
> > could even fork baselayout/etc if they wish and virtualize it in
> > @system.  Most things in Gentoo don't actually require a consensus to
> > move forward, especially if they aren't defaults.
> 
> if we deprecate the linker scripts in /usr/lib by stubbing out
>gen_usr_ldscript, then its not as simple as "maintainer's choice".

gen_usr_ldscript is only needed if you are using separate /usr without
an initramfs. This is unsupported and orthogonal to the usr merge.
 
> > 
> > In any case, what is the point of this thread?  If somebody wants to
> > implement a merged /usr what exactly is stopping them from doing so?
> 
> i'm against something that doesn't maintain backwards compat.

If there are ways that merging / into /usr does not maintain backward
compatibility, I want to know what they are.

This is not directed at anyone specifically, it is just a general
comment.

I've seen a lot of speculation on this thread about what might break,
and a lot of comments about a perceived removal  of choice.

Can someone help get a summary together? let's get a single message
summarizing everything.

Thanks,

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] usr merge

[Ian Stakenvicius]

> On Apr 8, 2016, at 8:42 PM, William Hubbs  wrote:
> 
>> On Fri, Apr 08, 2016 at 03:20:24PM -0700, Daniel Campbell wrote:
>> Based on what I've read here in the thread, merging /bin and /sbin
>> into /usr/{sbin,bin} is a matter of convenience by putting most of the
>> static parts of a running system into a single path. As mentioned by
>> some people, however, that's not enough to make deployment across
>> multiple machines super simple. The distros that focus on that aren't
>> rolling release like we are, and thus don't face the same difficulties
>> that we do. In addition, Gentoo supports a broad number of choices for
>> users and some are advocating for an option.
> 
> It is true that we offer a high degree of choice to users, but one of
> those choices is not which paths to install binaries and libraries
> into.
> 

Sure we do.  Users can do pretty much whatever convoluted file system hierarchy 
layout they want prior to unpacking the stage3 -- multiple volumes, symlinks or 
bind-mounts to combine dirs, etc etc.  

IMO support for this usr-merge should be left to that level of system 
configuration, as long as portage/other PMs support installing packages in such 
a way that the contents of /bin and /usr/bin don't collide with each other at 
merge time.

In other words, we should not drop any form of support at all for 
non-usr-merged systems.  Which means all of that ebuild cleanup WilliamH wants 
to do cannot happen.  Which, IMO, makes the whole thing moot.

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 09/04/16 14:37, Rich Freeman wrote:
> I've certainly haven't had many problems with dracut.  When it fails
> it is usually because I'm doing something ELSE that is off-the-wall
> and it just doesn't have a plugin for it yet.  (And in those cases it
> isn't like the kernel tends to get it right without an initramfs.)
> 
> I'd certainly want to test it on a merged /usr, but I'd be surprised
> if it doesn't work, since it was designed to run on distros that are
> using a merged /usr.

I think that should be the first thing to do not the last one =)

> In an ideal world, you might argue that / should just be a tmpfs or
> something almost as ephemeral.  It is just a place you hang everything
> else off of.

That would be the core concept, but then you can just not have /bin
/sbin /lib .

> The thing I like about the merge is that it basically puts all your
> distro-supplied stuff in one place.  /usr basically becomes the OS
> minus state.  If things started out that way and you just had a short
> stub loader that gets things initialized, and I were arguing that
> instead of that little initialization stub you should break up /usr so
> that the root count mount /usr, would that sound all that compelling?
> I think having it all in one mountpoint seems a lot more compelling. 

you cannot ever have everything in 1 mount point, you just move the
problem somewhere else you notice less (initramfs), but the problem
remains and either is solved or not.

having everything in /usr and then copy it over ${somewhere} is there,
it can be debated if /bin or initramfs is the best place to put it.

lu

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 08/04/16 14:55, Rich Freeman wrote:
> The purpose of a /usr merge is to get all the stateless stuff into one place.

beside what you have in /etc ...

usr-merge, in practice just moves early-boot/core tools where the rest
of the userspace lives.

> Some of the ultimate goals include:
> 1.  A read-only /usr

And mixing early-boot tools with post-boot userspace would help how?

> 2.  Having /usr signature-verified at boot

Because /etc is totally unimportant.

> 3.  Having everything that runs signature-checked before it is run

Because obviously you do not need to signature-check per executable.

> 4.  Having /usr shared across many containers/etc.

Because obviously it is the early-boot userspace spoiling this.

> 5.  Stateless systems - boot with a /usr and it creates the rest
> dynamically, and they're lost when the container is shut down.

Sounds backwards in many different ways.

> Put it this way, if you were designing a new OS from scratch today,
> would it make more sense to put all the distro-supplied
> binaries/libraries under a single path off the root, or off of many
> paths from the root?

You mean /usr/local ?

The whole thing ceases to be important once you have bind-mount and PATH
imho.

There is the specific need to have all the tools needed to boot in a
single place that can be accessed with ease.

It being /bin or initramfs or /boot/bin is completely cosmetic.

But you need a easy and reliable way to get it.

The idea of having / just holding the mount points and then have all the
other paths mounted by the early boot is fun only on paper I'm afraid.
(and we aren't even getting there since I bet /etc will stay in the root
partition for ages).

lu

Re: [gentoo-dev] Re: usr merge

[Nicolas Sebrecht]

On Fri, Apr 08, 2016 at 07:58:35AM +, Duncan wrote:

> > I would also re-iterate, as I'm sure you're aware .. there ARE
> > differences between sbin and bin .. unless of course you spend all your
> > time in a Rooted VM where it doesn't matter if you accidentally trash
> > your system. Some of us maintain a sensible user/superuser distinction
> > for a variety of reasons, and simplifying your filesystem to suit some
> > particular package style doesn't really sound like good reasoning for
> > causing a lot of headaches for maintainers and a distro overall.
> 
> But... the real important distinction in terms of user vs. superuser 
> executables is file ownership and permissions, not the directory they're 
> in.

No. With a lightweight / I can install systems with two root filesystems
that I rsync once I'm sure there's no regression. If one won't boot
after an upgrade, I can just reboot and select the other root filesystem
in grub.

This is much more easy than anything else.

-- 
Nicolas Sebrecht

Re: [gentoo-dev] usr merge

[Anthony G. Basile]

On 4/9/16 7:16 AM, Anthony G. Basile wrote:
> On 4/9/16 6:56 AM, Rich Freeman wrote:
>> Personally, I think our users would be better-served by making it a
>> choice.
> 
> Rich, we can bike shed for days.  It would just be nice to hear from
> base-layout people whether it will be a choice or not.  We need to know
> that so we can plan accordingly.
> 

@williamh

Is there a plan here that I can read?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 8:27 AM, Luca Barbato  wrote:
> On 09/04/16 13:53, Rich Freeman wrote:
>> Put the very same stuff in the initramfs?  Most initramfs creation
>> scripts should already do this automatically, and with compat symlinks
>> even those that don't probably will still end up doing it anyway..
>
> The question is different: do they work reliably?
>

I've certainly haven't had many problems with dracut.  When it fails
it is usually because I'm doing something ELSE that is off-the-wall
and it just doesn't have a plugin for it yet.  (And in those cases it
isn't like the kernel tends to get it right without an initramfs.)

I'd certainly want to test it on a merged /usr, but I'd be surprised
if it doesn't work, since it was designed to run on distros that are
using a merged /usr.

> usr-merge does not solve any problem in itself (and it is totally
> backwards, if somebody wants to simplify would do /usr -> /)

I don't really have any devotion to the particular design, but half
the point of the merge is to allow /usr to be read-only, on a
filesystem remotely mounted, and so on.

In an ideal world, you might argue that / should just be a tmpfs or
something almost as ephemeral.  It is just a place you hang everything
else off of.

But, of course moving all of /usr to / solves the early boot issue.
But, if you're going to do that you might as well just put /usr on
your root filesystem and have the same thing.

The thing I like about the merge is that it basically puts all your
distro-supplied stuff in one place.  /usr basically becomes the OS
minus state.  If things started out that way and you just had a short
stub loader that gets things initialized, and I were arguing that
instead of that little initialization stub you should break up /usr so
that the root count mount /usr, would that sound all that compelling?
I think having it all in one mountpoint seems a lot more compelling.

-- 
Rich

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 09/04/16 13:53, Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 7:41 AM, Luca Barbato  wrote:
>> On 05/04/16 03:19, William Hubbs wrote:
>>> Thoughts on any of this?
>>
>> The whole usr-merge moves the problem of putting stuff in / to putting
>> the very same stuff in the initrd when something different from busybox
>> (or equivalent) is needed to get the early boot mounting.
>>
>> Do we have a reliable way to address this now?
>>
> 
> Put the very same stuff in the initramfs?  Most initramfs creation
> scripts should already do this automatically, and with compat symlinks
> even those that don't probably will still end up doing it anyway..

The question is different: do they work reliably?

usr-merge does not solve any problem in itself (and it is totally
backwards, if somebody wants to simplify would do /usr -> /), but makes
more evident that you might need lots of the userspace to successfully
complete your early boot.

lu

Re: [gentoo-dev] Re: CVS headers in ebuilds

[Lars Wendler]

On Sat, 9 Apr 2016 12:12:44 +0200 Ole Reifschneider wrote:

>On Tue, Apr 05, 2016 at 12:30:15AM -0400, Jonathan Callen wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 04/04/2016 02:58 AM, Lars Wendler wrote:  
>> > On Sun, 3 Apr 2016 22:57:42 +0200 Ulrich Mueller wrote:
>> >  
>> >> Does anyone still use the CVS $Id$ keywords that are in all
>> >> ebuilds' headers, or are they being expanded anywhere? Or is
>> >> there any other reason why they should be kept?
>> >>
>> >> In fact, the council had already voted to drop them in its
>> >> 20141014 meeting:
>> >>
>> >> Can we drop CVS headers post-migration? Aye: blueness, creffett
>> >> (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh
>> >>
>> >>
>> >> Ulrich  
>> >
>> > Yes, I still use these lines to check for ebuild changes between
>> > portage and my personal overlay. So please keep this line.
>> >
>> > Thanks.
>> >
>> > Lars
>> >  
>>
>> I do the same (after enabling expansion in .git/info/attributes on
>> just "*.ebuild", I can even get a quick diff of what changed in
>> gentoo.git to update my overlay).
>>  
>
>Sounds cool. Can you please explain in more detail how you do this?
>
>Ole
>

Enable the ident feature for *.ebuild files in git:

  $ cat ~/gentoo/.git/info/attributes
  *.ebuild ident

Now re-checkout every ebuild you wanna track. 

  $ git checkout -- ~/gentoo/www-client/seamonkey/seamonkey-2.40.ebuild

Once you have done that those ebuilds will have some hash in the $Id$
field:

  $ grep '$Id' ~/gentoo/www-client/seamonkey/seamonkey-2.40.ebuild
  # $Id: 5ecd7709c6c8a316d9f005b4e4a0a54da81eb048 $

The same hash is in each corresponding ebuild in my personal overlay as
well. Occasionally I run a script to compare ebuilds from my overlay
with the one from the git tree. When the hash is different something in
the gentoo ebuild has changed and I can decide if I want to apply these
changes to ebuilds in my overlay as well.

I hope this brief explanation is sufficient.

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpjQtsVSDtLY.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 7:41 AM, Luca Barbato  wrote:
> On 05/04/16 03:19, William Hubbs wrote:
>> Thoughts on any of this?
>
> The whole usr-merge moves the problem of putting stuff in / to putting
> the very same stuff in the initrd when something different from busybox
> (or equivalent) is needed to get the early boot mounting.
>
> Do we have a reliable way to address this now?
>

Put the very same stuff in the initramfs?  Most initramfs creation
scripts should already do this automatically, and with compat symlinks
even those that don't probably will still end up doing it anyway..

Apologies if I missed the point of your question.  Are you looking for
a solution OTHER than an initramfs?  I imagine somebody could stick
some kind of wrapper on /, but in general if you want /usr not on the
root filesystem with a /usr merge you're going to have to jump through
hoops if you're not using an initramfs.  If you want a more
traditional configuration where / is used to mount /usr then a merged
/usr probably isn't for you.

-- 
Rich

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 05/04/16 03:19, William Hubbs wrote:
> Thoughts on any of this?

The whole usr-merge moves the problem of putting stuff in / to putting
the very same stuff in the initrd when something different from busybox
(or equivalent) is needed to get the early boot mounting.

Do we have a reliable way to address this now?

If the answer is no, maybe we should focus on solving it first and then
think how to move stuff around.

lu

Re: [gentoo-dev] usr merge

[Anthony G. Basile]

On 4/9/16 6:56 AM, Rich Freeman wrote:
> Personally, I think our users would be better-served by making it a
> choice.

Rich, we can bike shed for days.  It would just be nice to hear from
base-layout people whether it will be a choice or not.  We need to know
that so we can plan accordingly.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 1:32 AM,   wrote:
>
> now - an arbitrary decree comes down that *EVERYBODY* who wants a
> separate /usr needs to have initramfs.
>

The "decree" wasn't some kind of law that the Gentoo police will come
out to your house and arrest you for violating.

It was simply a recognition that we were already in a state where
booting a system without /usr mounted early can cause problems.  There
isn't really any solution to these problems (other than moving most of
/usr into /, which I doubt is the desire of anybody who puts /usr on a
separate filesystem), and it probably will only get worse.

The intent of the resolution was to not burden package maintainers to
have to cater to a use case that was already failing.

And the wording of the resolution doesn't mention the word "initramfs"
at all, precisely because we recognized that there were many ways to
work around the problem.

If you have concerns about the decision being arbitrary you might want
to read the original summary:
https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt

and log:
https://projects.gentoo.org/council/meeting-logs/20130813.txt

And of course you can read the list archives from the time where the
issue was extensively discussed.

> * IT DOES NOT MAKE THINGS ANY EASIER FOR THE ORIGINAL 5% EDGE CASES *.
> But the other 95% who could run separate /usr are now being told they
> must run initramfs "just because".  What does it accomplish?

I never really got the mentality that using an initramfs is a burden.

You can boot a kernel as an EFI program, but the reality is that many
if not most users of linux on EFI use a secondary bootloader.  Heck,
back in the old days you could actually boot linux directly from the
BIOS without any secondary bootloader, but this was so impractical
that even Linus now tells people to:
bugger_off_msg:
.ascii  "Use a boot loader.\r\n"
.ascii  "\n"
.ascii  "Remove disk and press any key to reboot...\r\n"
.byte   0
(and I must say that I admire the man with the guts to not insert a
carriage return when the carriage is already on the first column)

An initramfs is just a secondary bootloader for userspace.  I almost
always use them even if I'm just booting a VM with a single partition
on it.  If something goes wrong you can fall back to a shell in the
initramfs and it is like having a rescue disk built into your system
disk.  For a more complex setup it is much more robust than relying on
the kernel to find your root, and it also lets you build with a more
module-based kernel, which has some benefits as well even if you build
kernels tailored to each host.


-- 
Rich

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 12:06 AM, Anthony G. Basile  wrote:
> On 4/8/16 11:03 PM, Rich Freeman wrote:
>>
>> What problems are you anticipating, especially in light of the fact
>> that many distros actually do it this way already?
>
> RBAC policy files for one.  You'll probably break every single hardened
> gentoo server out there.

I wasn't suggesting that some adjustments to packages wouldn't be
needed to accommodate the change.  I was talking about the long-term,
after any necessary changes are made?

>
> scripts and programs that assume different executables with the same
> name at different points along the path, eg I know a company where
> they've set up an ssh wrapper at /usr/local/bin/ssh which wrap /usr/bin/ssh.

I get your point, but the actual case you cited wouldn't be affected
by a /usr merge.  I appreciate that there are cases where something
might be affected (though users shouldn't be sticking wrappers in
/usr/bin anyway without packaging them).

>>
>> I don't really have a problem with making it optional or the default.
>
> if we don't make it optional we're going to cause some serious headaches
> for people who are invested in the current status quo.

If you want to use a distro where you can heavily invest in the status
quo and not expect it to change I think you'd be better off with a
distro like RHEL, which targets this niche almost explicitly.

But, as I've said, I see no reason not to make it optional.  A big
part of why we CAN get stuff like this done is that we let people
migrate themselves at their own pace.

>>
>> It can also be left up to the maintainers, and of course somebody
>> could even fork baselayout/etc if they wish and virtualize it in
>> @system.  Most things in Gentoo don't actually require a consensus to
>> move forward, especially if they aren't defaults.
>
> if we deprecate the linker scripts in /usr/lib by stubbing out
> gen_usr_ldscript, then its not as simple as "maintainer's choice".

Well, I don't hear toolchain asking to retire that function.  If it is
their desire to stop maintaining it, then somebody else could of
course take over for them and preserve a choice.

>
>>
>> In any case, what is the point of this thread?  If somebody wants to
>> implement a merged /usr what exactly is stopping them from doing so?
>
> i'm against something that doesn't maintain backwards compat.
>

Well, we all have the freedom to fork baselayout if it isn't
maintained the way we want it to be.  Currently, no policy exists that
says the baselayout maintainers can't just maintain the package
however they want to (other than the general QA practice of
announcing/coordinating changes in advance with trackers/etc).  I
suppose if somebody wants to propose a policy that says otherwise it
is their freedom to do so.

Personally, I think our users would be better-served by making it a
choice.  That might be a choice that comes with some pros/cons, just
like the choice to use an initramfs, or the choice to run systemd, or
any other choice that we trust our users to make.

-- 
Rich

Re: [gentoo-dev] Re: CVS headers in ebuilds

[Ole Reifschneider]

On Tue, Apr 05, 2016 at 12:30:15AM -0400, Jonathan Callen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 04/04/2016 02:58 AM, Lars Wendler wrote:
> > On Sun, 3 Apr 2016 22:57:42 +0200 Ulrich Mueller wrote:
> >
> >> Does anyone still use the CVS $Id$ keywords that are in all
> >> ebuilds' headers, or are they being expanded anywhere? Or is
> >> there any other reason why they should be kept?
> >>
> >> In fact, the council had already voted to drop them in its
> >> 20141014 meeting:
> >>
> >> Can we drop CVS headers post-migration? Aye: blueness, creffett
> >> (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh
> >>
> >>
> >> Ulrich
> >
> > Yes, I still use these lines to check for ebuild changes between
> > portage and my personal overlay. So please keep this line.
> >
> > Thanks.
> >
> > Lars
> >
>
> I do the same (after enabling expansion in .git/info/attributes on
> just "*.ebuild", I can even get a quick diff of what changed in
> gentoo.git to update my overlay).
>

Sounds cool. Can you please explain in more detail how you do this?

Ole

Re: [gentoo-portage-dev] [PATCH] egencache --update-changelogs: fix timestamp assumptions (bug 579292)

[Zac Medico]

On 04/08/2016 06:12 PM, Brian Dolbec wrote:
> On Fri, 8 Apr 2016 00:29:40 -0700
> Zac Medico  wrote:
> 
>> On 04/07/2016 11:51 PM, Brian Dolbec wrote:
>>> the above looks good, but what about:
>>>
>>>
>>> [19:01]  just use --first-parent
>>> [19:01]  also take into account merge commits
>>> [19:03]  git really complicates ChangeLog generation
>>> in general [19:03]  because your ChangeLog should
>>> reflect when these commits became part of master, but you still
>>> need to perserve their messages [19:04] * zmedico is skeptical
>>> about the linearizability of the timestamps [19:04] 
>>> if you don't look at merge commits for your timestamps of changes,
>>> correct, it is not linear [19:05]  but if you take a
>>> set of commits and determine when they became part of master, it is
>>> linear [19:05]  so: git log --first-parent --format=%ct
>>> -1 . [19:05]  to get the last timestamp of changes to htat
>>> pkg [19:06]  then use that timestamp [19:06] 
>>> lmod = self.grab(['git', self._work_tree, 'log', '--format=%ct',
>>> '-1', '.']) [19:06]  that is the current code [19:06]
>>>  git log -m --first-parent --format=%ct -1 . [19:06]
>>>  so just add the --first-parent option? [19:07]
>>>  you want -m toolmod = self.grab(['git',
>>> self._work_tree, 'log', '--format=%ct', '-1', '.'])
>>>
>>> [19:06]  git log -m --first-parent --format=%ct -1 .
>>> [19:06]  so just add the --first-parent option?
>>> [19:07]  you want -m too
>>>
>>>
>>> Don't we need to add the -m --first-parent  ???
>>>   
>>
>> I don't know enough about how those options matter for git log
>> behavior, but I trust that dwfreed has good reasons to recommend
>> them. Maybe we should add them in a separate patch, possibly with
>> some explanation about how they are useful in this context.
> 
> They really matter when the tree gets crappy/stale merge commits from
> pull requests which play with the way the tree is considered.  In this
> particular case, it will ignore the branch history and only consider the
> merge commit that connects it to master.  Which is when we want to make
> the changelog entry, not when the (possibly stale) user commit was made.

Bug filed:

https://bugs.gentoo.org/show_bug.cgi?id=579402
-- 
Thanks,
Zac

[gentoo-dev] Re: pokit (was: usr merge)

[Duncan]

Ian Stakenvicius posted on Fri, 08 Apr 2016 10:50:24 -0400 as excerpted:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 08/04/16 10:33 AM, M. J. Everitt wrote:
>> I'll come back to the links a bit later, but is policykit and its
>> predecessor/derivatives now a mandatory part of a linux system?
>> 
>> Possibly crossing posts here, so apologies in advance .. ! :]
>> 
>> 
> polkit is only required/mandatory AFAIK in relation to dbus, which,
> at least for now and at least for non-systemd systems, is also
> technically optional.  And even within a dbus-managed environment I'm
> not sure if it's absolutely mandatory, tbh.

Polkit doesn't seem to be necessary here.  Systemd (if you're using it) 
does want (need I believe) dbus, but nothing I'm running, including kde-
plasma5 as my desktop, actually requires polkit.

Gentoo/kde folks strongly recommend polkit, and I believe it's required 
by some normal runtime-only dependencies such as the device-notifier and 
auto-mounter (solid's hardware-detect functionality), via the runtime-
only udisks2 (script) dependencies, but udisks2 pulls in all sorts of deps 
that I don't want, and because udisks2 is a runtime-only script dep, and 
I don't need nor want or need that automounting functionality in any 
case, I simply created a stub ebuild for it in my overlay that doesn't 
actually install any files or have any dependencies.  (Of course the old 
way to do that, via package.provided, can work as well, but it's 
deprecated, so a month or so ago I switched all package.provided packages 
to null-packages in my overlay.)

Problem solved.  No polkit, etc, deps, and inserted storage behaves like 
I want it to and waits until I issue a mount command or the like, before 
mounting. =:^)

Starting dolphin or gwenview complains to the journald (or syslog, I'm 
not sure which as it's syslog I actually monitor, with journald set to 
session-only tmpfs files) about a missing udisks2 dbus service or some 
such, but they still work, and I configured syslog-ng to filter those 
messages to /dev/null. =:^)

So polkit is definitely not required, even with systemd, dbus, and a kde-
plasma5 desktop, tho the latter will require jumping thru some hoops to 
stub out runtime-only deps.

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