Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[Ian Stakenvicius <axs@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/10/12 11:36 AM, William Hubbs wrote:
> Fellow Council Members:
> 
> We now have two methods of handling separate /usr configurations
> on Linux in the tree.
> 
> The first, and by far, the most flexable method is to use an
> initramfs. This method is now documented in the initramfs guide [1]
> and the handbooks. It would need to be used if a user needs
> specialized drivers running or modules loaded before the / or /usr
> file systems can be accessed. A non-inclusive list of these
> situations would be RAID, LVM2, ZFS, and software for encrypted
> file systems.
> 
> The second method can be used if the flexability of the first
> method is not needed. It involves re-emerging
> >=sys-apps/busybox-1.20.0 with the sep-usr use flag active and
> following the instructions in the elog messages. This is the way to
> support separate /usr without an initramfs if someone wants this.
> 
> The goal of separate /usr support is to insure that /usr is always 
> available when / is, and both of these methods meet this goal. If
> users switch to one of these methods, there is no further work
> required by us to support separate /usr configurations.
> 
> I have gone over this with Diego in QA, and he agrees that these
> are the methods we should use. That is why he is on the cc:
> specifically for this email.
> 
> I believe the only remaining step is for the council to approve
> this plan, so I would like it to be added to the agenda.
> 
> If this is approved, my plan will be to release a news item then 
> give a time window for users to read the news item and make their 
> decision [2]. Once the time window expires, we could assume that
> users with separate /usr have switched to using one of these two
> methods of supporting it.
> 

The end result of this assumption is that the use of
gen_usr_ldscript() and the move of libs from /usr/lib to /lib will
become deprecated, correct?  I think it's pertinent to note this (or
whatever other changes will then be requested/required for Council to
decide on) within this discussion, if not also within the "plan"..



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCP/msACgkQ2ugaI38ACPBEWgEAhz3bZDerxT/8bVt+1YzMoeDs
osrzwFXdi+06vF8MTjQBAI79FHc6IO3hjk9kbqD96Urh73zR1WCI2DtlpSypXBvj
=ZgY/
-----END PGP SIGNATURE-----