FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-22-2012, 09:11 AM
Steven J Long
 
Default Council meeting summary for 3 April 2012

Mike Gilbert wrote:

> On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long wrote:
>> And again, I ask: if it were *not* about running udev without an
>> initramfs, then why would anyone even be discussing the possibility of
>> patching or forking?
>>
>
> Here is my interpretation: the council voted on the following question:
>
> <ulm> The question is: "Decide on whether a separate /usr is still a
> supported
> configuration."
>
> It did not decide the method that would be used to accomplish this. A
> few council members (Chainsaw mainly) expressed a desire to do it
> without an initramfs, but an official stance on this was not put
> forward.
>
While I agree it would be better if the vote had specified "without an
initramfs" it seems clear to me that that was what was under discussion,
since a) Chainsaw was asked to describe the issue and specifically turned
down an initramfs, and b) udev with an initramfs already supports a separate
/usr partition, so why would the Council need to vote on it?

It's already supported if you use an initramfs, so there isn't anything to
discuss, nor vote on as technical policy.

> You are reading into it more that you should.

Well two of the votes specifically mention initramfs:
<Betelgeuse> As long as there is no automated help for people to
automatically get initramfs I vote yes
<hwoarang> i vote no, because diverting from upstream is not an ideal option
for me

If it were not about supporting users without an initramfs, why would a yes
vote mean diverging from upstream?

At this point, I'd like the Council to clarify. I really don't see what else
could have required a vote, and the whole discussion was about not using an
initramfs, who would maintain any patches needed, and what the potential
consequences might be.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
 
Old 04-22-2012, 09:28 AM
Steven J Long
 
Default Council meeting summary for 3 April 2012

Ulrich Mueller wrote:

> | 3. New udev and separate /usr partition (30 minutes)
> |
> | See [4]: "Decide on whether a separate /usr is still a supported
> | configuration. If it is, newer udev can not be stabled and
> | alternatives should be investigated. If it isn't, a lot of
> | documentation will have to be updated. (And an alternative should
> | likely still be provided.)"
> |
> | [4]
> | [<http://archives.gentoo.org/gentoo-
project/msg_c96d1b724cd736702820fa5ff1547557.xml>
>
From the first reply:

"To clarify, the question is whether or not we support a separate /usr
_without_ mounting it early via an initramfs."

I hope that settles that particular issue.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
 
Old 04-22-2012, 05:55 PM
Mike Gilbert
 
Default Council meeting summary for 3 April 2012

On 04/22/2012 05:28 AM, Steven J Long wrote:
> Ulrich Mueller wrote:
>
>> | 3. New udev and separate /usr partition (30 minutes)
>> |
>> | See [4]: "Decide on whether a separate /usr is still a supported
>> | configuration. If it is, newer udev can not be stabled and
>> | alternatives should be investigated. If it isn't, a lot of
>> | documentation will have to be updated. (And an alternative should
>> | likely still be provided.)"
>> |
>> | [4]
>> | [<http://archives.gentoo.org/gentoo-
> project/msg_c96d1b724cd736702820fa5ff1547557.xml>
>>
> From the first reply:
>
> "To clarify, the question is whether or not we support a separate /usr
> _without_ mounting it early via an initramfs."
>
> I hope that settles that particular issue.
>

Hmm... I see that in Zac's reply, thanks for that.

Unfortunately, from what I can tell, that clarification was not actually
part of the proposed agenda [5], nor was it directly referenced. So the
subject of the vote still seems open to interpretation.

Ultimately, the council's only "power" is to stop things from happening
under threat of expulsion from the project. I think it would be a
mistake for this particular council vote to be used as the sole
justification for preventing devs from committing changes that would
require an initramfs for separate /usr support. It simply does not seem
clear enough for that.

[5]
http://archives.gentoo.org/gentoo-project/msg_ac95bed78694852cd09f20a07437b805.xml
 
Old 04-22-2012, 06:13 PM
Zac Medico
 
Default Council meeting summary for 3 April 2012

On 04/22/2012 10:55 AM, Mike Gilbert wrote:
> On 04/22/2012 05:28 AM, Steven J Long wrote:
>> Ulrich Mueller wrote:
>>
>>> | 3. New udev and separate /usr partition (30 minutes)
>>> |
>>> | See [4]: "Decide on whether a separate /usr is still a supported
>>> | configuration. If it is, newer udev can not be stabled and
>>> | alternatives should be investigated. If it isn't, a lot of
>>> | documentation will have to be updated. (And an alternative should
>>> | likely still be provided.)"
>>> |
>>> | [4]
>>> | [<http://archives.gentoo.org/gentoo-
>> project/msg_c96d1b724cd736702820fa5ff1547557.xml>
>>>
>> From the first reply:
>>
>> "To clarify, the question is whether or not we support a separate /usr
>> _without_ mounting it early via an initramfs."
>>
>> I hope that settles that particular issue.
>>
>
> Hmm... I see that in Zac's reply, thanks for that.
>
> Unfortunately, from what I can tell, that clarification was not actually
> part of the proposed agenda [5], nor was it directly referenced. So the
> subject of the vote still seems open to interpretation.

Yeah, it almost seems as though the council was being intentionally
vague and leaving things open to interpretation. In response, we had
William post about the ">= udev-182 tracker" [1], to which Tony seemed
to respond positively [2].

[1]
http://archives.gentoo.org/gentoo-dev/msg_015e73cfccbd72fa956a8bdbc2e9cdc0.xml
[2]
http://archives.gentoo.org/gentoo-dev/msg_fb17ccaadc95c7f3f27d0613c13aa04e.xml
--
Thanks,
Zac
 
Old 04-23-2012, 01:25 AM
"Walter Dnes"
 
Default Council meeting summary for 3 April 2012

On Sun, Apr 22, 2012 at 06:28:08AM +0100, Steven J Long wrote

> <dberkholz> who's going to either "port" udev as necessary, or maintain an
> old version forever?
> <Chainsaw> I will keep an old version going until the end of time.
> <Chainsaw> dberkholz: My plan is to patch reasonable behaviour back into
> udev, and going with the upstream releases as long as it is feasible.

I use busybox's mdev, and it works fine for my simple system. See
https://wiki.gentoo.org/wiki/Mdev The busybox web site is
http://busybox.net/ and the maintenance is handled by them. The mailing
list info is at http://lists.busybox.net/mailman/listinfo/busybox

> To confirm again, that this is about without initramfs:
> <dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new
> udev that says "if you want separate /usr without initramfs, install old
> udev, mask new, or whatever"

systemd and udev are being merged into one tarball. For the "foreseeable
future", it will still build 2 separate binaries. What happens down the
road if/when it all becomes one combined binary?

> And again, I ask: if it were *not* about running udev without an
> initramfs, then why would anyone even be discussing the possibility
> of patching or forking?

Forking/patching udev would be a major undertaking. Maybe we'd be
better off making add-ons for mdev to provide missing udev functionality.
Note that busybox is intended for embedded systems, and they're not
going to add major additional functionality to the base code. That's
why I suggest optional add-ons for any additional functionality.

BTW, how would a non-programmer (at least not C programmer) like me
forward these ideas to the Gentoo Council?

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 04-23-2012, 06:04 AM
Zac Medico
 
Default Council meeting summary for 3 April 2012

On 04/22/2012 06:25 PM, Walter Dnes wrote:
> systemd and udev are being merged into one tarball. For the "foreseeable
> future", it will still build 2 separate binaries. What happens down the
> road if/when it all becomes one combined binary?

If becomes a problem, then it will be dealt with. There's no sense in
doing anything until it becomes a real problem though. Meanwhile, we can
sit back and relax. :-)

> Forking/patching udev would be a major undertaking. Maybe we'd be
> better off making add-ons for mdev to provide missing udev functionality.

Or, just use an initramfs. :-)

> BTW, how would a non-programmer (at least not C programmer) like me
> forward these ideas to the Gentoo Council?

You'll see an email on this list a week or two before the next council
meeting, and you can reply to that with your idea.
--
Thanks,
Zac
 
Old 04-23-2012, 06:30 AM
Fabian Groffen
 
Default Council meeting summary for 3 April 2012

On 22-04-2012 21:25:40 -0400, Walter Dnes wrote:
> BTW, how would a non-programmer (at least not C programmer) like me
> forward these ideas to the Gentoo Council?

Make sure you post pointers, with preferably a clear question, in reply
to the next call for agenda items (this Tuesday).


--
Fabian Groffen
Gentoo on a different level
 
Old 04-23-2012, 02:29 PM
"Walter Dnes"
 
Default Council meeting summary for 3 April 2012

On Sun, Apr 22, 2012 at 11:04:54PM -0700, Zac Medico wrote
> On 04/22/2012 06:25 PM, Walter Dnes wrote:

> > BTW, how would a non-programmer (at least not C programmer) like me
> > forward these ideas to the Gentoo Council?
>
> You'll see an email on this list a week or two before the next council
> meeting, and you can reply to that with your idea.

Thanks (and also to Fabian). I'll be watching this list.

--
Walter Dnes <waltdnes@waltdnes.org>
 
Old 04-28-2012, 09:09 PM
Mike Frysinger
 
Default Council meeting summary for 3 April 2012

On Wednesday 11 April 2012 12:10:05 Steven J Long wrote:
> William Hubbs wrote:
> > Another issue to consider is binaries that want to access things in
> > /usr/share/*. If a binary in /{bin,sbin} needs to access something in
> > /usr/share/*, you have two choices. move the binary to /usr or move the
> > thing it wants to access to / somewhere which would involve creating
> > /share. Actually there is another choice, but I don't want to go there.
> > That would be writing patches.
>
> I'm ignorant of which binaries do that?

off the top of my head:
- this is why /etc/localtime is no longer a symlink to
/usr/share/zoneinfo/
- this is why we have copies for a few terminals in /etc/terminfo from
/usr/share/terminfo/ ... hopefully the one you're using is listed there
- this is why we have to delay running keymap and consolefont init.d
scripts until after /usr has been mounted (/usr/share/keymaps
/usr/share/consolefont /usr/share/consoletrans)
- anything locale related doesn't work until /usr is mounted
(/usr/lib/locale /usr/share/locale)
- passwd changing relying on cracklib dicts won't work
(/usr/lib/cracklib_dict* /usr/share/misc/)

> (It's understood that you might not
> have manpages in rescue-mode.) OT, it's odd that nano is in /usr/bin but on
> my system at least it only links to /lib64.

/usr/bin/nano is a symlink
-mike
 
Old 04-28-2012, 11:44 PM
Luca Barbato
 
Default Council meeting summary for 3 April 2012

On 10/04/12 11:45, William Hubbs wrote:
> Also, I am going to reiterate what Greg said. This is not an issue with
> udev, but with the entire linux ecosystem.

As in bluez using dbus and some mount helpers requiring libraries in /usr.

> There are binaries in /{bin,sbin} which link against libraries in
> /usr/lib for example.

We could try to have an exact list and figure out exactly what is it and
how impacting it is. If any of those are needed for early-boot it would
be something to address nonetheless.

> Also, with the appropriate documentation changes, which are being worked
> on (see [1]), I feel that the statement above that newer udev can't be
> stabled should be re-evaluated.

lu

--

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
 

Thread Tools




All times are GMT. The time now is 07:07 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org