| 1 |
On Thu, Nov 08, 2012 at 04:16:35PM -0500, Rich Freeman wrote: |
| 2 |
> Summarizing some irc discussion: |
| 3 |
> |
| 4 |
> On Thu, Nov 8, 2012 at 1:53 PM, William Hubbs <williamh@g.o> wrote: |
| 5 |
> > I believe we can drop the gen_usr_ldscript question, yes, because if |
| 6 |
> > everything else happens, we can just have the toolchain guys make it a |
| 7 |
> > noop on Linux. |
| 8 |
> |
| 9 |
> There is disagreement over whether this is a good idea. Nobody |
| 10 |
> objects to dropping gen_usr_ldscript from discussion if it is left |
| 11 |
> alone, but it probably deserves some kind of consideration if we want |
| 12 |
> to change it (maybe not a council vote, but at least discussion). |
| 13 |
> |
| 14 |
> I think that the direction Gentoo wants to move in has no clear |
| 15 |
> consensus. I see several options: |
| 16 |
> 1. All boot-time files are in / (the old position, which we've agreed |
| 17 |
> to move away from). |
| 18 |
> 2. Files can be in / or /usr at maintainer discretion (align with |
| 19 |
> upstream, etc). |
| 20 |
> 3. All files should be in /usr - eventually /bin, /lib, and so on |
| 21 |
> should be empty (where Fedora is going). |
| 22 |
> |
| 23 |
> Dropping support for separate /usr without one of the solutions |
| 24 |
> already discussed is making the move from #1 to #2. I see modifying |
| 25 |
> gen_usr_ldscript as making the step from #2 to #3. |
| 26 |
|
| 27 |
No, it is part of the step from #1 to #2, since gen_usr_ldscript only |
| 28 |
moves shared libraries. If we turn this off, we end up leaving shared |
| 29 |
libraries where upstream intended them to be instead of putting them in |
| 30 |
/ and separating them from the static libraries. |
| 31 |
|
| 32 |
> Personally I don't have a problem with the /usr move, but that is a |
| 33 |
> big step, and I don't want to see lots of files moving to /usr without |
| 34 |
> maintainer involvement unless we're REALLY sure we want that. |
| 35 |
|
| 36 |
I'm not advocating right now for the /usr move, just what you called |
| 37 |
step #1 to #2. |
| 38 |
|
| 39 |
> Also, |
| 40 |
> before that function is modified to be a no-op on linux we should do |
| 41 |
> some serious testing - a lot of very important packages are going to |
| 42 |
> be affected. |
| 43 |
|
| 44 |
I do agree with testing, but this will all come after we implement |
| 45 |
separate /usr support; otherwise the testing will fail if you have |
| 46 |
separate /usr. |
| 47 |
|
| 48 |
> And of course this only affects libraries - movement of anything else |
| 49 |
> will require ebuild changes. |
| 50 |
|
| 51 |
Actually it only affects shared libraries. |
| 52 |
|
| 53 |
> > I would be ok with going a little longer than 30 days, but 6 months or |
| 54 |
> > a year might be a bit extreme. |
| 55 |
> |
| 56 |
> That was my thought as well - maybe 60 or 90 days is a better option. |
| 57 |
> Even 30 days though is a fair bit of time to migrate to initramfs. We |
| 58 |
> can always send out a news item that this is coming now if anybody |
| 59 |
> wants to mess with ~arch packages on a test machine before things are |
| 60 |
> stabilized. |
| 61 |
|
| 62 |
I have to get a new openrc stable and we need a newer genkernel before |
| 63 |
anything can start stabilizing. I don't want to send out any newsitems |
| 64 |
yet; I want to wait until the council says go ahead with this, and |
| 65 |
probably I'll send it out when that happens and we have the newer openrc |
| 66 |
and genkernel stabled and give a time window then. |
| 67 |
|
| 68 |
Also, if you don't want to use initramfs, you can use busybox[sep-usr]. |
| 69 |
Emerge it with that use flag and follow the instructions you get. |
| 70 |
William |
Archives