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

[Dale]

Michał Górny wrote:

On Tue, 17 Jan 2012 21:38:26 -0600
Dale  wrote:


Michał Górny wrote:

On Tue, 10 Jan 2012 19:14:52 +0100
Enrico Weigelt   wrote:


* Micha?? Górny   schrieb:


Does working hard involve compiling even more packages statically?

I guess, he means keeping udev in / ?

Because adding 80 KiB of initramfs hurts so much? We should then put
more work just to ensure that admin doesn't have to waste 15
minutes to recompile the kernel (if necessary), create an initramfs
and add it to bootloader config?


80Kbs?  You sure about that?  I somehow failed to mention this
before. I noticed it when I saw another reply to this post.  Reality
check:

80 KiB is enough for mounting plain /usr and booting with it. See
tiny-initramfs (but I haven't tested it thoroughly).



My plan is to have /usr on lvm.  I think it will end up larger and it 
still adds one more thing to break.


I really wish someone would get a better plan.  I think I see a garbage 
dump ahead with lots of Linux distros headed that way.


Dale

:-)  :-)

--
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Michał Górny]

On Tue, 17 Jan 2012 21:38:26 -0600
Dale  wrote:

> Michał Górny wrote:
> > On Tue, 10 Jan 2012 19:14:52 +0100
> > Enrico Weigelt  wrote:
> >
> >> * Micha?? Górny  schrieb:
> >>
> >>> Does working hard involve compiling even more packages statically?
> >> I guess, he means keeping udev in / ?
> > Because adding 80 KiB of initramfs hurts so much? We should then put
> > more work just to ensure that admin doesn't have to waste 15
> > minutes to recompile the kernel (if necessary), create an initramfs
> > and add it to bootloader config?
> >
> 
> 80Kbs?  You sure about that?  I somehow failed to mention this
> before. I noticed it when I saw another reply to this post.  Reality
> check:

80 KiB is enough for mounting plain /usr and booting with it. See
tiny-initramfs (but I haven't tested it thoroughly).

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

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

[Dale]

Mike Gilbert wrote:

On Tue, Jan 17, 2012 at 10:38 PM, Dale  wrote:

Michał Górny wrote:

On Tue, 10 Jan 2012 19:14:52 +0100
Enrico Weigeltwrote:


* Micha?? Górnyschrieb:


Does working hard involve compiling even more packages statically?

I guess, he means keeping udev in / ?

Because adding 80 KiB of initramfs hurts so much? We should then put
more work just to ensure that admin doesn't have to waste 15 minutes to
recompile the kernel (if necessary), create an initramfs and add it to
bootloader config?


80Kbs?  You sure about that?  I somehow failed to mention this before.  I
noticed it when I saw another reply to this post.  Reality check:

root@fireball / # ls -al /boot/initramfs-3.*
-rw-r--r-- 1 root root 5444240 Jan  1 07:24 /boot/initramfs-3.1.5-gentoo.img
-rw-r--r-- 1 root root 5515132 Jan  9 07:57 /boot/initramfs-3.2.0-r1.img
root@fireball / #

That's using the dracut tool.  Somehow, over 50Mbs is not anywhere close to
80Kbs, or maybe my calculator is broken.


Your calculator is off by a power of 10.




It is.  Still, 5Mbs is a lot larger than 80Kbs.

Thanks for the correction.

Dale

:-)  :-)

--
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Mike Gilbert]

On Tue, Jan 17, 2012 at 10:38 PM, Dale  wrote:
> Michał Górny wrote:
>>
>> On Tue, 10 Jan 2012 19:14:52 +0100
>> Enrico Weigelt  wrote:
>>
>>> * Micha?? Górny  schrieb:
>>>
 Does working hard involve compiling even more packages statically?
>>>
>>> I guess, he means keeping udev in / ?
>>
>> Because adding 80 KiB of initramfs hurts so much? We should then put
>> more work just to ensure that admin doesn't have to waste 15 minutes to
>> recompile the kernel (if necessary), create an initramfs and add it to
>> bootloader config?
>>
>
> 80Kbs?  You sure about that?  I somehow failed to mention this before.  I
> noticed it when I saw another reply to this post.  Reality check:
>
> root@fireball / # ls -al /boot/initramfs-3.*
> -rw-r--r-- 1 root root 5444240 Jan  1 07:24 /boot/initramfs-3.1.5-gentoo.img
> -rw-r--r-- 1 root root 5515132 Jan  9 07:57 /boot/initramfs-3.2.0-r1.img
> root@fireball / #
>
> That's using the dracut tool.  Somehow, over 50Mbs is not anywhere close to
> 80Kbs, or maybe my calculator is broken.
>

Your calculator is off by a power of 10.

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

[Dale]

Michał Górny wrote:

On Tue, 10 Jan 2012 19:14:52 +0100
Enrico Weigelt  wrote:


* Micha?? Górny  schrieb:


Does working hard involve compiling even more packages statically?

I guess, he means keeping udev in / ?

Because adding 80 KiB of initramfs hurts so much? We should then put
more work just to ensure that admin doesn't have to waste 15 minutes to
recompile the kernel (if necessary), create an initramfs and add it to
bootloader config?



80Kbs?  You sure about that?  I somehow failed to mention this before.  
I noticed it when I saw another reply to this post.  Reality check:


root@fireball / # ls -al /boot/initramfs-3.*
-rw-r--r-- 1 root root 5444240 Jan  1 07:24 /boot/initramfs-3.1.5-gentoo.img
-rw-r--r-- 1 root root 5515132 Jan  9 07:57 /boot/initramfs-3.2.0-r1.img
root@fireball / #

That's using the dracut tool.  Somehow, over 50Mbs is not anywhere close 
to 80Kbs, or maybe my calculator is broken.


Dale

:-)  :-)

--
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

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

[Rich Freeman]

On Tue, Jan 17, 2012 at 5:15 PM, Steven J Long
 wrote:
> The shifting nature of the arguments and the solutions makes me more
> uncomfortable that this hasn't been thought through even with the amount of
> feedback, and more importantly proper consideration to that feedback,
> required for a GLEP, let alone a change to base Linux filesystem
> specifications.
>

Keep in mind that the main proponents of this do not intend to issue
any GLEPs (they don't use Gentoo), and they may or may not get around
to changing FHS/etc.  They just intend to "do it" - and to some extent
they're already doing it.  Unless projects like udev get forked, we're
going there whether we want to or not - apparently a
soon-to-be-introduced version of udev already breaks when /usr isn't
mounted at boot.

If people don't like this, they need to start writing code, otherwise
they're going to get it by default...

Rich

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

[Steven J Long]

Michał Górny wrote:

> On Tue, 10 Jan 2012 12:56:11 -0600
> Dale  wrote:
>> How much time does it take when the initramfs fails?
> 
> The same when rootfs fails? Only the fact that initramfs is less likely
> to break than rootfs,
Seems to me for the average desktop user (who all this is aimed at, a 
narrowing of scope which smacks of poor design) both partitions will be on 
the same drive, so I don't know what you base that assertion on.

> and you have a pretty good opportunity now to
> experiment with it
Except we only have the tools we thought to include on the initramfs, not 
everything our nice distro system packagers, who have experience and 
feedback over a much broader spectrum than one user, provide for us on root.

>> I keep hoping that all the smart people involved in this will see the
>> mess it is creating. I'm not the sharpest tool in the shed but I'm
>> sharp enough to see the mess this is going to create and I'm just a
>> desktop user.  I feel sorry for people with more complicated systems
>> or remote ones.
> 
> The mess was created by people shouting 'hey, real men use
> separate /usr for no good reason! Be awesome like us'.
> 
No, it was created by coders not really grokking why people used /usr, 
finding it made integration tricky with dependent projects and then saying 
"oh well no-one has a good reason for a separate /usr, let's just ban it."
Now the stance has changed to "a separate /usr can be cool for snapshots, 
let's move *everything* there."

The shifting nature of the arguments and the solutions makes me more 
uncomfortable that this hasn't been thought through even with the amount of 
feedback, and more importantly proper consideration to that feedback, 
required for a GLEP, let alone a change to base Linux filesystem 
specifications.

Blanket dismissals of any conflicting opinion only worsens that feeling.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

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

[Steven J Long]

Michał Górny wrote:

> On Tue, 10 Jan 2012 19:14:52 +0100
> Enrico Weigelt  wrote:
> 
>> * Micha?? Górny  schrieb:
>> 
>> > Does working hard involve compiling even more packages statically?
>> 
>> I guess, he means keeping udev in / ?
> 
> Because adding 80 KiB of initramfs hurts so much? We should then put
> more work just to ensure that admin doesn't have to waste 15 minutes to
> recompile the kernel (if necessary), create an initramfs and add it to
> bootloader config?
> 
Isn't it also a question of making sure the new "rootfs is initfs" metaphor 
will always work, which requires all the standard utilities, plus any admin 
stuff that might be required, to be available in cases of system-recovery?

The latter is already somewhat nebulous for a lot of people, which is why 
it's nice when distributions do it for you (traditionally by making tools 
available on the rootfs.)

Point is, those utilities all need to be kept up to date with any changes in 
the underlying packages, which adds another layer of complexity (and may 
require some static builds.)
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

[Cyprien Nicolas]

"Paweł Hajdan, Jr." wrote:

On 1/17/12 6:35 PM, Zac Medico wrote:

I think what want already exists:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/info_vars

Am I right?


Not really. Even the example SYSTEM is not listed there, and as said
before we can't put every possible, now and in the future, bad variable
name there.

I think another line should be added to emerge --info, like this (just
an example, most variables omitted):

Variables defined in make.conf: CFLAGS, CXXFLAGS, SYSTEM, ...



It seems that emerge --info --verbose does that (at least with portage-2.2)

I'm used to define USE_*¹ variables in my make.conf in order to split 
out global USEs. Those variables does not appear in the emerge --info 
output, but they are visible if I had --verbose.


--
Cyprien
Fulax on #gentoo-lisp

1. This naming scheme isn't safe either, as USE_EXPAND and USE_ORDER are 
make.conf settings

Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

[Pacho Ramos]

El mar, 17-01-2012 a las 18:23 +0100, "Paweł Hajdan, Jr." escribió:
> On 1/16/12 12:36 PM, Pacho Ramos wrote:
> > I agree but, why not *also* make portage warn people when they are
> > exporting some "known to break" variables in their make.conf?
> 
> That'd require coming up with such list of "known bad" variable names,
> and generally I don't think blacklisting is very effective.
> 
> It's relatively easy to invent a breaking name, but hard to enumerate
> them all.
> 
> Anyway, that's a superset of my original proposal, so I'm fine if
> someone wants to experiment with it.
> 

The idea would be to fill that list when we get a bug report with user
having problems due a variable and, then, prevent it from occurring in
the future. This is similar to add "unset BLABLABLA" to our ebuilds when
we get a bug report but with the advantage of covering more possible
packages that could fail if the same variable is set.


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

Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

[Jeroen Roovers]

On Tue, 17 Jan 2012 18:41:47 +0100
""Paweł Hajdan, Jr.""  wrote:

> Not really. Even the example SYSTEM is not listed there, and as said
> before we can't put every possible, now and in the future, bad
> variable name there.

Wouldn't the environment file reveal these bad variables? emerge output
has suggested attaching that to any bug reports for a long time, even
though usually it isn't necessary.


 jer

Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

[Paweł Hajdan, Jr.]

On 1/17/12 6:35 PM, Zac Medico wrote:
> On 01/16/2012 02:54 AM, "Paweł Hajdan, Jr." wrote:
>> People frequently break their systems by exporting weird variables like
>> SYSTEM from /etc/make.conf (USE variable "grouping").
>>
>> Example here: 
>>
>> What do you think about adding list of variables in make.conf to emerge
>> --info ? I know we can always ask for the make.conf, but it either
>> requires asking for a large amount of info up front, or increases the
>> number of round-trips (emerge --info looks normal, ask for make.conf).
> 
> I think what want already exists:
> 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/info_vars
> 
> Am I right?

Not really. Even the example SYSTEM is not listed there, and as said
before we can't put every possible, now and in the future, bad variable
name there.

I think another line should be added to emerge --info, like this (just
an example, most variables omitted):

Variables defined in make.conf: CFLAGS, CXXFLAGS, SYSTEM, ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

[Zac Medico]

On 01/16/2012 02:54 AM, "Paweł Hajdan, Jr." wrote:
> People frequently break their systems by exporting weird variables like
> SYSTEM from /etc/make.conf (USE variable "grouping").
> 
> Example here: 
> 
> What do you think about adding list of variables in make.conf to emerge
> --info ? I know we can always ask for the make.conf, but it either
> requires asking for a large amount of info up front, or increases the
> number of round-trips (emerge --info looks normal, ask for make.conf).

I think what want already exists:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/info_vars

Am I right?

-- 
Thanks,
Zac

Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

[Paweł Hajdan, Jr.]

On 1/16/12 12:36 PM, Pacho Ramos wrote:
> I agree but, why not *also* make portage warn people when they are
> exporting some "known to break" variables in their make.conf?

That'd require coming up with such list of "known bad" variable names,
and generally I don't think blacklisting is very effective.

It's relatively easy to invent a breaking name, but hard to enumerate
them all.

Anyway, that's a superset of my original proposal, so I'm fine if
someone wants to experiment with it.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-util/chromium-tools

[Paweł Hajdan, Jr.]

# Determined by the maintaining team to be no longer useful.
# Removal in 30 days (02/16/2012).
dev-util/chromium-tools



signature.asc
Description: OpenPGP digital signature