Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


waltdnes at waltdnes

Apr 22, 2012, 6:25 PM

Post #26 of 43 (263 views)
Permalink
Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

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 [at] waltdnes>


zmedico at gentoo

Apr 22, 2012, 11:04 PM

Post #27 of 43 (258 views)
Permalink
Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

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


grobian at gentoo

Apr 22, 2012, 11:30 PM

Post #28 of 43 (261 views)
Permalink
Re: Council meeting summary for 3 April 2012 [In reply to]

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
Attachments: signature.asc (0.19 KB)


waltdnes at waltdnes

Apr 23, 2012, 7:29 AM

Post #29 of 43 (262 views)
Permalink
Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

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 [at] waltdnes>


vapier at gentoo

Apr 28, 2012, 2:09 PM

Post #30 of 43 (257 views)
Permalink
Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

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
Attachments: signature.asc (0.82 KB)


lu_zero at gentoo

Apr 28, 2012, 4:44 PM

Post #31 of 43 (256 views)
Permalink
Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

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


mgorny at gentoo

Apr 28, 2012, 11:44 PM

Post #32 of 43 (258 views)
Permalink
Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

On Sat, 28 Apr 2012 16:44:57 -0700
Luca Barbato <lu_zero [at] gentoo> wrote:

> On 10/04/12 11:45, William Hubbs wrote:
> > 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.

I have already opened bugs for many of them. But the list will increase
in time, and we'll either move a lot of libraries to /lib* or decide to
go the other way.

Did someone mentioned mentioning two cross-linked program/data trees
(well, three or four in our case) with fuzzy classification rules is
against KISS?

--
Best regards,
Michał Górny
Attachments: signature.asc (0.31 KB)


lu_zero at gentoo

Apr 29, 2012, 12:04 AM

Post #33 of 43 (256 views)
Permalink
Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

On 28/04/12 23:44, Michał Górny wrote:
> I have already opened bugs for many of them. But the list will increase
> in time, and we'll either move a lot of libraries to /lib* or decide to
> go the other way.

repeat after me EARLY BOOT, as in initramfs. In initramfs you don't have
/usr with everything there because you are supposed to mount it. If you
need something (e.g. a mount helper using libs living somewhere) you
need to put it there, if you don't have a way to be aware of which is
where then you'll have users experiencing problems.

The proper way to fix it is either fix the programs or find replacement
that have less or no dependencies.

> Did someone mentioned mentioning two cross-linked program/data trees
> (well, three or four in our case) with fuzzy classification rules is
> against KISS?

Enumerate them, I'm sick of vague problems.

lu

--

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


zmedico at gentoo

Apr 29, 2012, 3:40 PM

Post #34 of 43 (254 views)
Permalink
Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

On 04/29/2012 12:04 AM, Luca Barbato wrote:
> On 28/04/12 23:44, Michał Górny wrote:
>> I have already opened bugs for many of them. But the list will increase
>> in time, and we'll either move a lot of libraries to /lib* or decide to
>> go the other way.
>
> repeat after me EARLY BOOT, as in initramfs. In initramfs you don't have
> /usr with everything there because you are supposed to mount it. If you
> need something (e.g. a mount helper using libs living somewhere) you
> need to put it there, if you don't have a way to be aware of which is
> where then you'll have users experiencing problems.
>
> The proper way to fix it is either fix the programs or find replacement
> that have less or no dependencies.

Maybe it's reasonable for the initramfs to utilize a config file from
/etc of the future root filesystem, but having in depend on files from
the future /usr seems like a strange idea. Wouldn't it make more sense
to bundle all dependencies into the initramfs, so that it's mostly
self-contained, rather than have it be dependent on files from the
future root filesystem (or future /usr)?
--
Thanks,
Zac


lu_zero at gentoo

Apr 29, 2012, 4:38 PM

Post #35 of 43 (253 views)
Permalink
Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

On 29/04/12 15:40, Zac Medico wrote:
> Maybe it's reasonable for the initramfs to utilize a config file from
> /etc of the future root filesystem, but having in depend on files from
> the future /usr seems like a strange idea. Wouldn't it make more sense
> to bundle all dependencies into the initramfs, so that it's mostly
> self-contained, rather than have it be dependent on files from the
> future root filesystem (or future /usr)?

Well it is a bit unreasonable even rely on foreign /etc.

The root problem is that what you want to use for early boot should not
have huge deps and that assumption fails for a number of reasons, I
guess mostly due the fact who writes some software doesn't expect it to
be run on early boot =\

lu

--

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


slong at rathaus

May 4, 2012, 7:50 AM

Post #36 of 43 (240 views)
Permalink
Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

Walter Dnes wrote:

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

Does it handle USB and other media hotplug? That's the real killer for
desktops. (Running scripts in response to events is another issue, and what
has led to the udev problem.)

>
>> 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?
>
Well I've read assertions that it will be possible to build udev without
systemd for distros and users who want it, and this is supposedly a firm
commitment into the future. Then again, experience doesn't bode well for
those kind of commitments.

(It's much easier to introduce coupling between software in the same
package. GregKH has also mooted a tightly-coupled "core" Linux distro, which
afaict is the same reasoning as GnomeOS, and /that/ sounds like a
clusterfsck waiting to happen.)

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

The point I was making was that it couldn't even be an issue, _unless_ one
were talking about an install without an initramfs, since udev with an
initramfs supports a split /usr.

(That's required for the usr-bin merge to be useful, since the idea is to
enable snapshotting of all distribution binaries; after years of rubbishing
any possible reason admins might have for a split /usr, it's now critical to
a major 'new' feature of Fedora, and all the traditional benefits are
selling-points of the "new design".)

As for the effort, so long as you don't need udev to create nodes for
localmount, you don't need an initramfs with either our patched approach, or
an earlymounts initscript, and now there's vapier's busybox applet to do the
mounts for you. None of which require any modification to udev, nor
maintenance of an initrd and the binaries therein.

Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


slong at rathaus

May 4, 2012, 8:10 AM

Post #37 of 43 (246 views)
Permalink
Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

Mike Gilbert wrote:

> On 04/22/2012 05:28 AM, Steven J Long wrote:
>> "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.
>
Chainsaw proposed the item. zmedico immediately clarified that it was about
supporting separate /usr without an initramfs mounting it.

Chainsaw was asked to describe the issue. He was asked whether a "minimal
universal" initramfs was a sufficient solution, and he explicity turned it
down. All further discussion was about who would continue to maintain any
patches that might be needed.

Again, those could not have been needed, unless one were discussing split
/usr without an initramfs, since udev with an initramfs already supports a
separate /usr. Or do you disagree?

To say that it was not referenced in the discussion seems disingenuous: it
_was_ the topic of discussion.

> 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.
>
Woah, no-one's even talking about anything along those lines.

The Council *does* decide on overall technical policy, and this procedure is
used for eg resolution of PMS and EAPI issues. Obviously, like all
collaborative processes, and indeed policing in general, it only works by
consent.

There's no issue of changes to udev, since those can be handled at
initscript/ busybox-applet level for those who want to continue without an
initramfs and split partitioning.

There might be future problems with linkage, but I've already stated a
couple of times, that the same issues arise for the newer use-case of an
initramfs, and it would make sense to tackle those systematically for at
least some tools like lvm and mdadm. Given the systematic ability, it's much
easier for users to apply elsewhere, and has other uses (basically doing it
right is LDEPEND or required-link deps which slot operators do *not* cover.)

What's wrong with doing that, so we all cooperate and we all benefit,
instead of arguing?

Anyhow, wrt what the Council was actually discussing (remember that split
/usr with an initramfs is a technical non-issue) as before, I'd like the
Council just to clarify.

Guess I'll have to raise it on the agenda so they have to discuss it again?

Regards,
Steve.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


slong at rathaus

May 4, 2012, 8:20 AM

Post #38 of 43 (240 views)
Permalink
Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

Zac Medico wrote:

> On 04/22/2012 10:55 AM, Mike Gilbert wrote:
>> On 04/22/2012 05:28 AM, Steven J Long wrote:
>>> 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.

Wow, man, never thought I'd see *you* weasel out of something like that ;)

> In response, we had
> William post about the ">= udev-182 tracker" [1], to which Tony seemed
> to respond positively [2].
>
That was about process to do with stabilisation. Of course having a tracker
to monitor any issues is a positive step.

It doesn't say anything at all about what the base requirement was, nor what
was up for discussion at the meeting. You yourself clarified that it was
about no initramfs as soon as it was raised to Council: that was the only
thing that could cause a technical issue, specifically to users who have
setup according to official documentation, requiring a policy decision.

And that's what all the discussion was about: the consequence of making that
policy decision (ie who would maintain patches, which are no longer needed.)

Still, this got silly weeks ago. Clearly Council needs to vote again with
clear wording, or people will keep trying to pretend that they weren't
discussing what they were asked to discuss.

Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


slong at rathaus

May 4, 2012, 9:36 AM

Post #39 of 43 (241 views)
Permalink
Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

Mike Frysinger wrote:

> 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/*.
>>
>> I'm ignorant of which binaries do that?
>
> off the top of my head:

Ah thanks, this is what I was after: interested in which ones make use of a
rescue-shell or initramfs more difficult.

> - this is why /etc/localtime is no longer a symlink to
> /usr/share/zoneinfo/
- don't think that makes any difference to rescue situation.

> - 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
- while unfortunate, I'd say ditto since user can always copy any required
file themselves for their particular setup.

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

- this is one that really is annoying; having your keyboard switched to US
layout. It's not totally insurmountable from a UK keyboard, but I'd imagine
eg a Dvorak user would have trouble.

du -hs here, shows:
1.1M /usr/share/keymaps
1000K /usr/share/consolefonts
504K /usr/share/consoletrans

..which is nothing I personally would mind on rootfs, if it meant my rescue-
shell used my keyboard layout.

> - anything locale related doesn't work until /usr is mounted
> (/usr/lib/locale /usr/share/locale)

This doesn't affect me as I'm fine with en_US vs en_GB.
1.7M /usr/lib/locale
53M /usr/share/locale
..is a lot heavier, though.

(Sorry, I'm not stating that anyone is going to want to maintain this, I'm
just scoping out how much data we're talking about, and how it important it
is. While latter might change according to user as here, it would be cool if
it were nothing more than setting up a few symlinks during install.)

> - passwd changing relying on cracklib dicts won't work
> (/usr/lib/cracklib_dict* /usr/share/misc/)
>
I can see you might want the option after an attack on a host. NFC how
viable moving and linking is (not sure what it uses in /usr/share/misc but I
for one would love the pci and usb stuff [just over 1M] in rootfs. kk I know
it's not going to happen officially ;) but libs are less than 300k here.

>> (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
ah d'oh, ta; i see it was switched back in 2004.

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

Yeah, based on above, I'd feel okay about /lib/share/foo personally, linked
to from /usr/share/foo on both bare rootfs with no mounts, and standard
/usr. (Similar for /usr/lib/foo to /lib/foo.) If it's in
/usr/{share,lib}/dir/* then the possibility at least of moving it fairly
simply, exists. Otherwise you're into dealing with a build-system of one
sort or another.

Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


vapier at gentoo

May 4, 2012, 9:47 AM

Post #40 of 43 (242 views)
Permalink
Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

On Friday 04 May 2012 12:36:20 Steven J Long wrote:
> Mike Frysinger wrote:
> > - this is why /etc/localtime is no longer a symlink to
> > /usr/share/zoneinfo/
>
> - don't think that makes any difference to rescue situation.

no, but that isn't the driving factor here. programs get executed before /usr
is mounted which means these things need to be available. otherwise, dates in
logs and such are wrong. the rest of your comments should be taken in the
same light.
-mike
Attachments: signature.asc (0.82 KB)


slong at rathaus

May 4, 2012, 10:24 AM

Post #41 of 43 (242 views)
Permalink
Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

Mike Frysinger wrote:

> On Friday 04 May 2012 12:36:20 Steven J Long wrote:
>> Mike Frysinger wrote:
>> > - this is why /etc/localtime is no longer a symlink to
>> > /usr/share/zoneinfo/
>>
>> - don't think that makes any difference to rescue situation.
>
> no, but that isn't the driving factor here. programs get executed before
> /usr is mounted which means these things need to be available. otherwise,
> dates in logs and such are wrong. the rest of your comments should be
> taken in the same light.

OK, fair enough. I still don't think it makes much difference in terms of
the viability of moving certain directories (for the admin, not the distro)
given the current setup. Nonetheless, I'll just wait til your busybox applet
is the officially-supported method of split /usr without an initramfs ;)

(It'll mean openrc by default gets a faster bootup, which matters to some
people.)

Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


zmedico at gentoo

May 4, 2012, 12:50 PM

Post #42 of 43 (243 views)
Permalink
Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

On 05/04/2012 08:20 AM, Steven J Long wrote:
> Zac Medico wrote:
>
>> On 04/22/2012 10:55 AM, Mike Gilbert wrote:
>>> On 04/22/2012 05:28 AM, Steven J Long wrote:
>>>> 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.
>
> Wow, man, never thought I'd see *you* weasel out of something like that ;)
>
>> In response, we had
>> William post about the ">= udev-182 tracker" [1], to which Tony seemed
>> to respond positively [2].
>>
> That was about process to do with stabilisation. Of course having a tracker
> to monitor any issues is a positive step.
>
> It doesn't say anything at all about what the base requirement was, nor what
> was up for discussion at the meeting. You yourself clarified that it was
> about no initramfs as soon as it was raised to Council:

I *tried* to clarify it, but was apparently unsuccessful, since the
agenda item contained no mention of initramfs:

http://archives.gentoo.org/gentoo-dev/msg_2eaaf4a4e302bf0e6c20accaec61db82.xml

> that was the only
> thing that could cause a technical issue, specifically to users who have
> setup according to official documentation, requiring a policy decision.

I'm not so sure. The one question that really stood out for me was the
question of whether or not newer udev could be stabilized, since it
would be problematic for separate-/usr-without-initramfs systems.
--
Thanks,
Zac


gregkh at gentoo

May 4, 2012, 6:05 PM

Post #43 of 43 (242 views)
Permalink
Re: Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 [In reply to]

On Fri, May 04, 2012 at 03:50:24PM +0100, Steven J Long wrote:
> >> 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?
> >
> Well I've read assertions that it will be possible to build udev without
> systemd for distros and users who want it, and this is supposedly a firm
> commitment into the future. Then again, experience doesn't bode well for
> those kind of commitments.
>
> (It's much easier to introduce coupling between software in the same
> package. GregKH has also mooted a tightly-coupled "core" Linux distro, which
> afaict is the same reasoning as GnomeOS, and /that/ sounds like a
> clusterfsck waiting to happen.)

"mooted"?

And since when does having a set of tightly coupled base libraries and
systems that work well together somehow turn into "GnomeOS"? Reaching
like that is just foolish on your part.

greg k-h

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.