* [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
[not found] <20353.41193.129711.306663@a1i15.kph.uni-mainz.de>
@ 2012-04-08 22:04 ` Greg KH
2012-04-08 23:28 ` Rich Freeman
2012-04-10 18:45 ` [gentoo-dev] " William Hubbs
0 siblings, 2 replies; 111+ messages in thread
From: Greg KH @ 2012-04-08 22:04 UTC (permalink / raw
To: gentoo-dev
On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> New udev and separate /usr partition
> ====================================
> 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.)
>
> The council has voted in favour of a separate /usr being supported
> (5 yes, 1 no vote).
What?
> During the discussion, some concerns were raised that we might not be
> able to provide a modified or forked udev version. Chainsaw assured
> that if necessary, he will maintain a udev version that supports said
> configuration.
It isn't udev that is the problem here, it's the loads of other
packages. udev is just being "nice" and pointing out that the user has
a problem.
> It was remarked that a solution that comprises both the forked udev
> version (separate /usr) and the latest versions is possible and
> therefore should not block either way preferred by users.
How in the world are you going to support this type of thing, when it
isn't udev that is the issue?
And udev isn't even the problem, all you need is to mount your /usr from
initramfs. So, the original proposal wasn't even a correct/valid
proposal in the first place.
Papering over the issue, by just keeping udev from reporting the
problem is NOT a valid solution. You are shooting the messenger here.
greg k-h
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-08 22:04 ` [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Greg KH
@ 2012-04-08 23:28 ` Rich Freeman
2012-04-09 18:09 ` [gentoo-dev] " Steven J Long
2012-04-10 18:45 ` [gentoo-dev] " William Hubbs
1 sibling, 1 reply; 111+ messages in thread
From: Rich Freeman @ 2012-04-08 23:28 UTC (permalink / raw
To: gentoo-dev
On Sun, Apr 8, 2012 at 6:04 PM, Greg KH <gregkh@gentoo.org> wrote:
> On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
>> The council has voted in favour of a separate /usr being supported
>> (5 yes, 1 no vote).
>
> What?
Perhaps the council should be the ones to clarify, but I think the
vote only was for separate /usr being supported. The irc log seemed a
bit more nuanced than perhaps came out in the summary. Maybe I'm
misreading it. I didn't see anything in the log about a decision that
newer versions of udev are not able to be stabled.
So, as to what "a separate /usr being supported" means, the impression
I got was "don't worry if you're running it, you'll have an upgrade
path." Right now it sounds like the proposed upgrade path is that
some devs will fork udev and keep it running more like the current one
(presumably breaking in the same situations that it already does
today).
> And udev isn't even the problem, all you need is to mount your /usr from
> initramfs. So, the original proposal wasn't even a correct/valid
> proposal in the first place.
Well, as far as I can tell the proposal that was voted on didn't even
mention udev at all, or initramfs. But, as you point out using an
initramfs is likely to be more reliable.
I'm sure the same arguments were going around back when people were
advocating for dropping bootloader support in the kernel and telling
people to bugger_off_msg. An initramfs creates more flexibility, at
the cost of an extra layer of software, just like grub. The main
downside to it is that it tends to require more maintenance, though if
you build the necessary drivers to mount /usr into the kernel I
imagine that an initramfs would probably work across differing kernel
versions.
In any case, we should still be updating documentation/etc regardless.
A better guide to dracut/genkernel would be useful no matter how this
turns out. I'd like to see stable Gentoo stay current with udev in
any case, but I don't mind using a forked version as long as it is of
similar quality to the original. As you've pointed out already, that
may not actually help people with a separate /usr, so I'd encourage
people to get an initramfs working.
Rich
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-08 23:28 ` Rich Freeman
@ 2012-04-09 18:09 ` Steven J Long
2012-04-09 19:20 ` Zac Medico
0 siblings, 1 reply; 111+ messages in thread
From: Steven J Long @ 2012-04-09 18:09 UTC (permalink / raw
To: gentoo-dev
Rich Freeman wrote:
> On Sun, Apr 8, 2012 at 6:04 PM, Greg KH <gregkh@gentoo.org> wrote:
>> On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
>
>>> The council has voted in favour of a separate /usr being supported
>>> (5 yes, 1 no vote).
>>
>> What?
>
> Perhaps the council should be the ones to clarify, but I think the
> vote only was for separate /usr being supported. The irc log seemed a
> bit more nuanced than perhaps came out in the summary. Maybe I'm
> misreading it. I didn't see anything in the log about a decision that
> newer versions of udev are not able to be stabled.
>
> So, as to what "a separate /usr being supported" means, the impression
> I got was "don't worry if you're running it, you'll have an upgrade
> path." Right now it sounds like the proposed upgrade path is that
> some devs will fork udev and keep it running more like the current one
> (presumably breaking in the same situations that it already does
> today).
>
Well I definitely read it as "supported without an initramfs":
<Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
<Chainsaw> Betelgeuse: No.
Otherwise there is no contention, nor need to consider patches.
>> And udev isn't even the problem, all you need is to mount your /usr from
>> initramfs. So, the original proposal wasn't even a correct/valid
>> proposal in the first place.
>
If udev simply requires partitions mounted before it is started, that allows
those of us who don't need udev to get partitions mounted (still not sure
how that works if you do) to continue with initscript-based approaches (eg
those mentioned at end.)
> Well, as far as I can tell the proposal that was voted on didn't even
> mention udev at all, or initramfs. But, as you point out using an
> initramfs is likely to be more reliable.
>
As above, the discussion prior certainly mentioned initramfs, and being able
not to use one seems to be a requirement, or there'd be no need to talk
about "forking" udev to maintain the old behaviour (which I believe is the
ability to retry failed scripts in udev-postmount, which ideally requires
udev to distinguish between failures due to file not found, and true
failures.)
> I'm sure the same arguments were going around back when people were
> advocating for dropping bootloader support in the kernel and telling
> people to bugger_off_msg. An initramfs creates more flexibility, at
> the cost of an extra layer of software, just like grub. The main
> downside to it is that it tends to require more maintenance, though if
> you build the necessary drivers to mount /usr into the kernel I
> imagine that an initramfs would probably work across differing kernel
> versions.
>
One thing that has bothered me with the mooting of an initramfs as the new
rescue system that rootfs has traditionally been, is at the we are told at
the same time that the initramfs can be very minimal. If so, how does it
provide the same capabilities as rootfs (for those of us who can localmount
without udev-configured devices)?
> In any case, we should still be updating documentation/etc regardless.
> A better guide to dracut/genkernel would be useful no matter how this
> turns out. I'd like to see stable Gentoo stay current with udev in
> any case, but I don't mind using a forked version as long as it is of
> similar quality to the original. As you've pointed out already, that
> may not actually help people with a separate /usr, so I'd encourage
> people to get an initramfs working.
>
There are two alternatives currently on the forums which don't require an
initramfs, nor patches to udev. earlymounts[1] is an initscript which runs
before udev in sysinit, which appears to be having teething troubles eg with
fsck, and I have posted an approach[2] which allows udev to start after
localmount, ie in the manner it used to, which has no problems with fsck,
but is trickier to setup.
Of course, neither of these can be used if you have root on lvm or encrypted
partitions, ie the cases which traditionally required an initrd, or if you
have need of udev-configured devices to get through localmount.
[1] http://forums.gentoo.org/viewtopic-t-918466.html
[2] http://forums.gentoo.org/viewtopic-t-901206.html
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-09 18:09 ` [gentoo-dev] " Steven J Long
@ 2012-04-09 19:20 ` Zac Medico
2012-04-11 2:28 ` [gentoo-dev] " Steven J Long
0 siblings, 1 reply; 111+ messages in thread
From: Zac Medico @ 2012-04-09 19:20 UTC (permalink / raw
To: gentoo-dev
On 04/09/2012 11:09 AM, Steven J Long wrote:
> One thing that has bothered me with the mooting of an initramfs as the new
> rescue system that rootfs has traditionally been, is at the we are told at
> the same time that the initramfs can be very minimal. If so, how does it
> provide the same capabilities as rootfs (for those of us who can localmount
> without udev-configured devices)?
We've had some discussion on this before [1], and I've suggested to copy
the content of livecd/usb recovery disk onto a spare partition so that
you can boot into that if necessary. The advantage of using this
approach is that it eliminates the burden of maintaining the "/ is a
self-contained boot disk that's independent of /usr" use case.
[1]
http://archives.gentoo.org/gentoo-dev/msg_ceb908069aafdfff50e7f2d0732bf209.xml
--
Thanks,
Zac
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-08 22:04 ` [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Greg KH
2012-04-08 23:28 ` Rich Freeman
@ 2012-04-10 18:45 ` William Hubbs
2012-04-11 9:34 ` Ralph Sennhauser
2012-04-28 23:44 ` Luca Barbato
1 sibling, 2 replies; 111+ messages in thread
From: William Hubbs @ 2012-04-10 18:45 UTC (permalink / raw
To: gentoo-dev; +Cc: council
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
> On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> > New udev and separate /usr partition
> > ====================================
> > 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.)
There is no disagreement about whether or not separate /usr will be
supported. No one has said that you can't have a separate /usr
partition.
Was the council aware of the tracker bug we have open where we are
tracking the documentation changes explaining how to build an initramfs
if you have a separate /usr partition [1]?
Also, I am going to reiterate what Greg said. This is not an issue with
udev, but with the entire linux ecosystem.
There are binaries in /{bin,sbin} which link against libraries in
/usr/lib for example.
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.
William
[1] https://bugs.gentoo.org/show_bug.cgi?id=407959
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-09 19:20 ` Zac Medico
@ 2012-04-11 2:28 ` Steven J Long
2012-04-11 4:09 ` Zac Medico
2012-04-11 11:44 ` [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Rich Freeman
0 siblings, 2 replies; 111+ messages in thread
From: Steven J Long @ 2012-04-11 2:28 UTC (permalink / raw
To: gentoo-dev
Zac Medico wrote:
> On 04/09/2012 11:09 AM, Steven J Long wrote:
>> One thing that has bothered me with the mooting of an initramfs as the
>> new rescue system that rootfs has traditionally been, is at the we are
>> told at the same time that the initramfs can be very minimal. If so, how
>> does it provide the same capabilities as rootfs (for those of us who can
>> localmount without udev-configured devices)?
>
> We've had some discussion on this before [1], and I've suggested to copy
> the content of livecd/usb recovery disk onto a spare partition so that
> you can boot into that if necessary. The advantage of using this
> approach is that it eliminates the burden of maintaining the "/ is a
> self-contained boot disk that's independent of /usr" use case.
>
It's a nice idea, and could also be done without an initramfs, ofc. You
mention configuring "initramfs to mount that as the root if something goes
wrong with your real root."
Thing is, for most desktop/laptop installs, if something goes wrong mounting
root from hard-disk, it's likely that booting into another partition will go
wrong too. It's pretty rare to get errors just on rootfs, that aren't to do
with the whole drive, and aren't fixed by fsck on a stable fs like ext3. (If
you do, you have to go to backups ofc, and would be wise to suspect the
whole drive.) At least, that's been my experience using separate partitions
for everything.
In that circumstance, if a rescue shell weren't available, (you're able to
boot the kernel or the the spare partition can't be booted to) I would just
boot the latest sysresccd that was around, if not able to download from
another box. If it were really that bad, I'd likely want to reinitialise any
failing partition, and would probably want a recent minimal install disk.
Boot up problems which need admin-work on Gentoo, ime, tend to be about
system upgrades not playing nicely, rather than the kernel unable to boot at
all (once you know which drivers you need for eg PCI/SATA drives built-in,
you usually are able to get at least root consistently, on an older kernel
if you're upgrading.)
Again, being able to boot into the machine, and have the rootfs at hand for
say dispatch-conf and rc-update, works nicely. A rescue partition would
effectively work the same as a live-disk, in that you'd need to do all the
chrooting etc afaics, and would need to be maintained to stay current.
I suppose you could script that, but again, it just seems like a lot of
bother to implement an "alternative" that doesn't actually gain anything
over the traditional setup (plus making sure that partitions are mounted
before udev starts.)
As for the burden of ensuring that binaries installed to /{s,}bin don't link
to libs in /usr, why not just automate a QA check for that, and let
developers decide whether a fix is necessary? After all, core packages that
do that even when configured with prefix and execprefix = /, aren't so
portable, and Gentoo has always championed "doing the right thing" wrt
helping upstream fix portability issues.
I realise "core" is subjective, but it amounts to "what our lovely devs
decide on for us" which is part of the reason you choose a distro, and the
trust you place in its developers.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 2:28 ` [gentoo-dev] " Steven J Long
@ 2012-04-11 4:09 ` Zac Medico
2012-04-11 5:18 ` William Hubbs
2012-04-11 14:13 ` [gentoo-dev] " Steven J Long
2012-04-11 11:44 ` [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Rich Freeman
1 sibling, 2 replies; 111+ messages in thread
From: Zac Medico @ 2012-04-11 4:09 UTC (permalink / raw
To: gentoo-dev
On 04/10/2012 07:28 PM, Steven J Long wrote:
> I suppose you could script that, but again, it just seems like a lot of
> bother to implement an "alternative" that doesn't actually gain anything
> over the traditional setup (plus making sure that partitions are mounted
> before udev starts.)
At least in the case of udev, we gain from not having to maintain a fork.
> As for the burden of ensuring that binaries installed to /{s,}bin don't link
> to libs in /usr, why not just automate a QA check for that, and let
> developers decide whether a fix is necessary? After all, core packages that
> do that even when configured with prefix and execprefix = /, aren't so
> portable, and Gentoo has always championed "doing the right thing" wrt
> helping upstream fix portability issues.
If the relevant ebuild developers really want to support that, it's fine
I guess. Hopefully that won't involve using static links as workarounds
for cross-/usr dependencies.
--
Thanks,
Zac
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 4:09 ` Zac Medico
@ 2012-04-11 5:18 ` William Hubbs
2012-04-11 16:10 ` [gentoo-dev] " Steven J Long
2012-04-11 14:13 ` [gentoo-dev] " Steven J Long
1 sibling, 1 reply; 111+ messages in thread
From: William Hubbs @ 2012-04-11 5:18 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]
On Tue, Apr 10, 2012 at 09:09:03PM -0700, Zac Medico wrote:
> On 04/10/2012 07:28 PM, Steven J Long wrote:
> > I suppose you could script that, but again, it just seems like a lot of
> > bother to implement an "alternative" that doesn't actually gain anything
> > over the traditional setup (plus making sure that partitions are mounted
> > before udev starts.)
>
> At least in the case of udev, we gain from not having to maintain a fork.
>
> > As for the burden of ensuring that binaries installed to /{s,}bin don't link
> > to libs in /usr, why not just automate a QA check for that, and let
> > developers decide whether a fix is necessary? After all, core packages that
> > do that even when configured with prefix and execprefix = /, aren't so
> > portable, and Gentoo has always championed "doing the right thing" wrt
> > helping upstream fix portability issues.
>
> If the relevant ebuild developers really want to support that, it's fine
> I guess. Hopefully that won't involve using static links as workarounds
> for cross-/usr dependencies.
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.
The best way to solve all cross / - /usr dependencies imo is the /usr
merge (moving everything from /{bin,sbin,lib*} to the counterparts in
/usr), which has been discussed pretty extensively on this list, and
there hasn't been a lot of opposition to it.
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-10 18:45 ` [gentoo-dev] " William Hubbs
@ 2012-04-11 9:34 ` Ralph Sennhauser
2012-04-28 23:44 ` Luca Barbato
1 sibling, 0 replies; 111+ messages in thread
From: Ralph Sennhauser @ 2012-04-11 9:34 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]
On Tue, 10 Apr 2012 13:45:04 -0500
William Hubbs <williamh@gentoo.org> wrote:
> On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
> > On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> > > New udev and separate /usr partition
> > > ====================================
> > > 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.)
>
> There is no disagreement about whether or not separate /usr will be
> supported. No one has said that you can't have a separate /usr
> partition.
>
Isn't meant /usr without initramfs, independent of how "broken" some
people precieve it?
> Was the council aware of the tracker bug we have open where we are
> tracking the documentation changes explaining how to build an
> initramfs if you have a separate /usr partition [1]?
>
That's an effort I welcome either way. So thanks for that.
> Also, I am going to reiterate what Greg said. This is not an issue
> with udev, but with the entire linux ecosystem.
> There are binaries in /{bin,sbin} which link against libraries in
> /usr/lib for example.
>
With udev-182 its no longer only the ecosystem which produce some
broken products but udev itself which is broken. Otherwise we would
have gone on like we always did, right?
> 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.
>
Long term newer udevs will be stabilized and I'm positive it wont take
as long as grub2 or portage-2.2 ;)
There is no particular hurry as far as I know so let's give Chainsaw
some time to look into an udev patch and don't go with the 30 day
with bug fixing rule.
Support for initramfs was rather poor until recently. For instance
dracut-0.17-r3 (haven't tested 0.18 so far) was the first to actually
produce a usable initramfs for me. Thus far I crafted them manually if
needed. Personally I would like to see the initramfs situation further
improved, this includes genkernel and dracut stable on all platforms and
then give it time to let the knowlage spread or alternatively an udev
patch which allows current setups to continue to work before the
council re-evaluates the udev stabilization again.
Cheers
Ralph
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=407959
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 2:28 ` [gentoo-dev] " Steven J Long
2012-04-11 4:09 ` Zac Medico
@ 2012-04-11 11:44 ` Rich Freeman
2012-04-11 15:09 ` [gentoo-dev] " Steven J Long
1 sibling, 1 reply; 111+ messages in thread
From: Rich Freeman @ 2012-04-11 11:44 UTC (permalink / raw
To: gentoo-dev
On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> As for the burden of ensuring that binaries installed to /{s,}bin don't link
> to libs in /usr, why not just automate a QA check for that, and let
> developers decide whether a fix is necessary? After all, core packages that
> do that even when configured with prefix and execprefix = /, aren't so
> portable, and Gentoo has always championed "doing the right thing" wrt
> helping upstream fix portability issues.
The only issue with that logic is that upstream is perfectly aware of
what they're doing already, and bugs are likely to be closed as
WONTFIX. So, all the QA checks would do is ensure that we slowly
start maintaining forks of more and more packages. Right now the
problem is probably manageable, but I'm not convinced it will stay
that way. Once upstream developers consider all constraints to be
removed on their dependencies you could see a lot of stuff getting
pulled into root if you tried to enforce this rule.
In any case, it sounds like the directive is to keep limping along for
a while longer, and that makes sense anyway until docs/etc are
improved. I agree with Ralph's suggestion that the newer initramfs
tools should be stabilized as well.
Rich
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 4:09 ` Zac Medico
2012-04-11 5:18 ` William Hubbs
@ 2012-04-11 14:13 ` Steven J Long
2012-04-11 19:57 ` Zac Medico
1 sibling, 1 reply; 111+ messages in thread
From: Steven J Long @ 2012-04-11 14:13 UTC (permalink / raw
To: gentoo-dev
Zac Medico wrote:
> On 04/10/2012 07:28 PM, Steven J Long wrote:
>> I suppose you could script that, but again, it just seems like a lot of
>> bother to implement an "alternative" that doesn't actually gain anything
>> over the traditional setup (plus making sure that partitions are mounted
>> before udev starts.)
>
> At least in the case of udev, we gain from not having to maintain a fork.
>
"Making sure that partitions are mounted before udev starts" is a lot less
of an ask than setting up an initramfs, and changing the way we've worked
for years. It's what you proposed: an earlymounts init script, or patches to
Gentoo initscripts to do the same thing. Neither involves any patches to
udev proper, so no fork needs to be maintained.
>> As for the burden of ensuring that binaries installed to /{s,}bin don't
>> link to libs in /usr, why not just automate a QA check for that, and let
>> developers decide whether a fix is necessary? After all, core packages
>> that do that even when configured with prefix and execprefix = /, aren't
>> so portable, and Gentoo has always championed "doing the right thing" wrt
>> helping upstream fix portability issues.
>
> If the relevant ebuild developers really want to support that, it's fine
> I guess. Hopefully that won't involve using static links as workarounds
> for cross-/usr dependencies.
Well I for one wouldn't like that, so no argument there: it's only for where
the package would be definitely be considered for inclusion in a rescue-
disk/ initramfs/ partition, like say lvm2, mount or fsck. While you might
not always be able to access the manpages, a system admin would want at
least the binaries available.
I think it was mgorny who posted a check, which is why I brought it up.
Perhaps an opt-in check if some variable is set, would be better? That way,
only a maintainer who wants to mark the package as system-critical, and is
happy to deal with linkage issues for binaries (including just deciding that
some aren't so critical, which implies an optional exclusion variable, or
listing binaries that should be checked) would set it, in the interests of
overall portability and helping traditional users.
If a maintainer isn't interested, or upstream don't like it (ie won't accept
bugs with such a setup even when linkage is not the issue), there's no
additional burden.
Of course, if no developer thinks it's worth doing, the discussion is moot.
It would seem at the least useful, if not necessary, however, if Gentoo is
going to continue to support the traditional split /usr setup.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 11:44 ` [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Rich Freeman
@ 2012-04-11 15:09 ` Steven J Long
2012-04-11 16:55 ` Rich Freeman
0 siblings, 1 reply; 111+ messages in thread
From: Steven J Long @ 2012-04-11 15:09 UTC (permalink / raw
To: gentoo-dev
Rich Freeman wrote:
> On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
> <slong@rathaus.eclipse.co.uk> wrote:
>> As for the burden of ensuring that binaries installed to /{s,}bin don't
>> link to libs in /usr, why not just automate a QA check for that, and let
>> developers decide whether a fix is necessary? After all, core packages
>> that do that even when configured with prefix and execprefix = /, aren't
>> so portable, and Gentoo has always championed "doing the right thing" wrt
>> helping upstream fix portability issues.
>
> The only issue with that logic is that upstream is perfectly aware of
> what they're doing already, and bugs are likely to be closed as
> WONTFIX.
It would only be for packages that are specifically marked, the ones you'd
want in an initramfs. The "fix" is simply making sure the buildsystem
doesn't look in /usr/lib etc when so marked, and checking that binaries
don't link from / to anywhere but /lib*. If they do, it's up to the
maintainer as to whether it's an issue.
You'd only file an upstream bug if the build-system was looking in /usr/lib
despite being told not to (eg when only given -L /lib.) Making sure libs are
available in the right location is down to the distro, same as for the
initramfs.
> So, all the QA checks would do is ensure that we slowly
> start maintaining forks of more and more packages. Right now the
> problem is probably manageable, but I'm not convinced it will stay
> that way. Once upstream developers consider all constraints to be
> removed on their dependencies you could see a lot of stuff getting
> pulled into root if you tried to enforce this rule.
>
That might be true for some Linux-only packages, but I really find it hard
to believe that any upstream targetting more than one OS (just adding a BSD
is enough) with software that could be considered critical (I for one would
include all POSIX utilities as well as basic stuff like mount, fsck and
lvm2) would want to ignore this kind of thing; if the build-system is
ignoring configuration, it's a bug.
Regardless of how Linux might move (and personally I think there is a lot
more opposition to this than devs realise, as it throws the idea behind
userspace compatibility completely out of the window, in that it massively
impacts a generation of *nix working practices, even before one considers
systemd's single-point of kitchen-sink failure) taking away choice from end-
users for no appreciable gain in functionality or efficiency seems like a
bad idea.
I understand that the argument is "this is more efficient for our
development" but we're not talking about every package in the tree. Just the
binaries we might need in an initramfs; making sure their linkage is sound,
is likely to be useful for that case too, since it's an even more restricted
environment.
Wrt constraints on dependencies being removed, I don't really see that as
upstream's job; they simply specify the dependencies required and where they
actually are is up to the distro, and provided to the build by a mechanism
like pkg-config, or just flags from the package manager. Distros always have
been about managing dependencies for us.
> In any case, it sounds like the directive is to keep limping along for
> a while longer,
I read the decision from the Council to be "we will continue to support the
traditional split /usr eg with lvm, and no initramfs" and a Council member
put himself forward to maintain patches to udev to ensure that going
forward, since it is needed in his employment.
Given that we can do it with initscripts, and don't need to fork udev at
all, what's the problem?
It would only be for users who specifically opt in, knowing that they don't
need udev to localmount, and with the awareness that they might need to
configure things-- which any Gentoo user is used to hearing and evaluating.
> and that makes sense anyway until docs/etc are
> improved. I agree with Ralph's suggestion that the newer initramfs
> tools should be stabilized as well.
>
No argument on either of those.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 5:18 ` William Hubbs
@ 2012-04-11 16:10 ` Steven J Long
2012-04-28 21:09 ` Mike Frysinger
0 siblings, 1 reply; 111+ messages in thread
From: Steven J Long @ 2012-04-11 16:10 UTC (permalink / raw
To: gentoo-dev
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? (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.
We're only discussing the same tools one might need in an initramfs, wherein
they presumably also need to have their linkage checked.
> The best way to solve all cross / - /usr dependencies imo is the /usr
> merge (moving everything from /{bin,sbin,lib*} to the counterparts in
> /usr), which has been discussed pretty extensively on this list, and
> there hasn't been a lot of opposition to it.
>
There's been quite a bit of vocal opposition on the forums[1], and it's
users who've setup their machines in line with Gentoo docs that this is
going to impact. Even the link that was given to Red-Hat discussion about
this a while back, showed opposition to the move from their users.
[1] http://forums.gentoo.org/viewtopic-t-914852.html
'It's about as good an idea as putting the entire content of /etc into a
file and calling it "The Registry"
Oh, wait, that's already been done and shown not to work.'
NeddySeagoon - whose experience in system-administration and IT I'll bow to
anyday.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 15:09 ` [gentoo-dev] " Steven J Long
@ 2012-04-11 16:55 ` Rich Freeman
2012-04-22 3:30 ` [gentoo-dev] " Steven J Long
0 siblings, 1 reply; 111+ messages in thread
From: Rich Freeman @ 2012-04-11 16:55 UTC (permalink / raw
To: gentoo-dev
On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> That might be true for some Linux-only packages, but I really find it hard
> to believe that any upstream targetting more than one OS (just adding a BSD
> is enough) with software that could be considered critical (I for one would
> include all POSIX utilities as well as basic stuff like mount, fsck and
> lvm2) would want to ignore this kind of thing; if the build-system is
> ignoring configuration, it's a bug.
The issue is that if udev requires libfoo, then libfoo must not be in
/usr. If libfoo is libx11 or dbus or some other complex library, that
will pull in a bunch of other stuff as well. However, I doubt that
the maintainers of all those libraries would consider them
boot-essential, so they may not be inclined to make the move.
Obviously we're not there now, but it is a possible consequence of
moving in this direction.
Keep in mind that systemd in particular does not aim to be
cross-platform - they advertise this as one of their core features.
Since tight integration is their goal that could slowly bring in a lot
of other stuff. The main platform pushing it along is Fedora, and
they're aiming to move everything into /usr, so this is a non-issue
for them.
> I read the decision from the Council to be "we will continue to support the
> traditional split /usr eg with lvm, and no initramfs" and a Council member
> put himself forward to maintain patches to udev to ensure that going
> forward, since it is needed in his employment.
>
> Given that we can do it with initscripts, and don't need to fork udev at
> all, what's the problem?
I can't really comment on what the decision from the Council actually
was. However, maintaining patches to udev is effectively the same
thing as forking it. Right now it probably isn't hard, and over time
that could change.
The only time patches != fork is if the patches have been submitted
upstream and are likely to be merged.
In any case, it isn't a crisis now and waiting a little to see which
way the wind ends up blowing probably makes sense.
Rich
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 14:13 ` [gentoo-dev] " Steven J Long
@ 2012-04-11 19:57 ` Zac Medico
2012-04-22 2:43 ` [gentoo-dev] " Steven J Long
0 siblings, 1 reply; 111+ messages in thread
From: Zac Medico @ 2012-04-11 19:57 UTC (permalink / raw
To: gentoo-dev
On 04/11/2012 07:13 AM, Steven J Long wrote:
> Zac Medico wrote:
>
>> On 04/10/2012 07:28 PM, Steven J Long wrote:
>>> I suppose you could script that, but again, it just seems like a lot of
>>> bother to implement an "alternative" that doesn't actually gain anything
>>> over the traditional setup (plus making sure that partitions are mounted
>>> before udev starts.)
>>
>> At least in the case of udev, we gain from not having to maintain a fork.
>>
> "Making sure that partitions are mounted before udev starts" is a lot less
> of an ask than setting up an initramfs, and changing the way we've worked
> for years. It's what you proposed: an earlymounts init script, or patches to
> Gentoo initscripts to do the same thing. Neither involves any patches to
> udev proper, so no fork needs to be maintained.
It's not generally practical to do mounts prior to starting udev, since
udev can may be needed to create the device nodes that are needed for
for performing the mounts. Maybe a subset of users can get away with it
by relying on devtmpfs and having the drivers built into the kernel, but
that won't work for everyone.
--
Thanks,
Zac
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 19:57 ` Zac Medico
@ 2012-04-22 2:43 ` Steven J Long
2012-04-22 2:53 ` Rich Freeman
0 siblings, 1 reply; 111+ messages in thread
From: Steven J Long @ 2012-04-22 2:43 UTC (permalink / raw
To: gentoo-dev
Zac Medico wrote:
> On 04/11/2012 07:13 AM, Steven J Long wrote:
>> Zac Medico wrote:
>>
>>> On 04/10/2012 07:28 PM, Steven J Long wrote:
>>>> I suppose you could script that, but again, it just seems like a lot of
>>>> bother to implement an "alternative" that doesn't actually gain
>>>> anything over the traditional setup (plus making sure that partitions
>>>> are mounted before udev starts.)
>>>
>>> At least in the case of udev, we gain from not having to maintain a
>>> fork.
>>>
>> "Making sure that partitions are mounted before udev starts" is a lot
>> less of an ask than setting up an initramfs, and changing the way we've
>> worked for years. It's what you proposed: an earlymounts init script, or
>> patches to Gentoo initscripts to do the same thing. Neither involves any
>> patches to udev proper, so no fork needs to be maintained.
>
> It's not generally practical to do mounts prior to starting udev, since
> udev can may be needed to create the device nodes that are needed for
> for performing the mounts. Maybe a subset of users can get away with it
> by relying on devtmpfs and having the drivers built into the kernel, but
> that won't work for everyone.
OFC not: the generic method is to use an initramfs. But many of us *do* have
the drivers for the device nodes built-in: it's part of the initial setup in
configuring a kernel (manually) and getting it to boot.
I can't speak for others, but that level of control is why I, for one, chose
Gentoo in the first place. I don't see the need for a source-based distro to
include everything and the kitchen-sink: that principle applies via USE-
flags, and it applies via having a lean kernel that doesn't contain modules
for 15 PCI controllers my motherboard doesn't have, and never could have.
The Council has voted that Gentoo continue to support that subset, without
an initramfs.
I'm glad you accept that we don't need to fork udev to do this, though, so
there isn't that maintenance issue, beyond Gentoo initscripts (and if there
should be in future, a Council member has already committed to overseeing
that work.)
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 2:43 ` [gentoo-dev] " Steven J Long
@ 2012-04-22 2:53 ` Rich Freeman
2012-04-22 5:28 ` [gentoo-dev] " Steven J Long
0 siblings, 1 reply; 111+ messages in thread
From: Rich Freeman @ 2012-04-22 2:53 UTC (permalink / raw
To: gentoo-dev
On Sat, Apr 21, 2012 at 10:43 PM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> The Council has voted that Gentoo continue to support that subset, without
> an initramfs.
Citation, please?
Rich
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 16:55 ` Rich Freeman
@ 2012-04-22 3:30 ` Steven J Long
0 siblings, 0 replies; 111+ messages in thread
From: Steven J Long @ 2012-04-22 3:30 UTC (permalink / raw
To: gentoo-dev
Rich Freeman wrote:
> On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long wrote:
>> That might be true for some Linux-only packages, but I really find it
>> hard to believe that any upstream targetting more than one OS (just
>> adding a BSD is enough) with software that could be considered critical
>> (I for one would include all POSIX utilities as well as basic stuff like
>> mount, fsck and lvm2) would want to ignore this kind of thing; if the
>> build-system is ignoring configuration, it's a bug.
>
> The issue is that if udev requires libfoo, then libfoo must not be in
> /usr. If libfoo is libx11 or dbus or some other complex library, that
> will pull in a bunch of other stuff as well. However, I doubt that
> the maintainers of all those libraries would consider them
> boot-essential, so they may not be inclined to make the move.
>
> Obviously we're not there now, but it is a possible consequence of
> moving in this direction.
>
Sure, but I'm curious: how would you set up an initramfs under those
conditions?
Where I'm going with this, is that in both cases (an initramfs or a
traditional rootfs system) we need to be aware of what libs pull in what.
Given that, there is actually common work both sides need.
If we could focus on that, we'd all actually be cooperating to fix things
for both setups, instead of arguing about which is best. :)
> Keep in mind that systemd in particular does not aim to be
> cross-platform - they advertise this as one of their core features.
> Since tight integration is their goal that could slowly bring in a lot
> of other stuff. The main platform pushing it along is Fedora, and
> they're aiming to move everything into /usr, so this is a non-issue
> for them.
>
I have a feeling that "integration" is being used as an excuse to avoid
thinking about coupling and cohesion.
>> I read the decision from the Council to be "we will continue to support
>> the traditional split /usr eg with lvm, and no initramfs" and a Council
>> member put himself forward to maintain patches to udev to ensure that
>> going forward, since it is needed in his employment.
>>
>> Given that we can do it with initscripts, and don't need to fork udev at
>> all, what's the problem?
>
> I can't really comment on what the decision from the Council actually
> was.
Well, I've stated that several times now, and included the snippet from the
log where Betelgeuse specifically asked Chainsaw to clarify that a
"universal" minimal initramfs was not good enough, which was confirmed.
If Council members disagree with that interpretation, I'd welcome their
clarification.
Split /usr with lvm was specifically discussed as a use-case, since it has
been outlined in Gentoo documentation.
> However, maintaining patches to udev is effectively the same
> thing as forking it. Right now it probably isn't hard, and over time
> that could change.
>
> The only time patches != fork is if the patches have been submitted
> upstream and are likely to be merged.
>
udev != openrc or any other init system, which is what we are patching[1] so
that udev is not started til after localmount, should the user set a
currently unsupported udev.conf option (initramfs="no").
We're only making minor shell-script modifications to udev and udev-mount
initscripts, not openrc itself.
Earlymounts[2] is simply an additional initscript.
IOW no patches to udev whatsoever, so no fork.
> In any case, it isn't a crisis now and waiting a little to see which
> way the wind ends up blowing probably makes sense.
>
No indeed: those of us who wish to stay with our traditional setup, who have
already configured our machines to localmount with built-in modules, can use
the patched initscripts/earlymounts. What we'd like is for those, or
equivalent functionality, to be maintained within Gentoo so we don't have to
tweak patches whenever udev-init-scripts is updated, or in the earlymounts
case there appear to be more issues, and those could use input from devs
imo.
I prefer the patched approach, even if it is a bit more setup and I am
biased, since it appears to have less potential for interaction with other
stuff: if you never needed an initramfs before, and can localmount with just
kernel-created device-nodes (eg: you need to change fstab from using
/dev/vg/lv to /dev/mapper/vg-lv for lvm), then you're fine.
[1] http://forums.gentoo.org/viewtopic-t-901206.html
[2] http://forums.gentoo.org/viewtopic-t-918466.html
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 2:53 ` Rich Freeman
@ 2012-04-22 5:28 ` Steven J Long
2012-04-22 6:00 ` Mike Gilbert
2012-04-23 1:25 ` [gentoo-dev] " Walter Dnes
0 siblings, 2 replies; 111+ messages in thread
From: Steven J Long @ 2012-04-22 5:28 UTC (permalink / raw
To: gentoo-dev
Rich Freeman wrote:
>> The Council has voted that Gentoo continue to support that subset,
>> without an initramfs.
>
(The "subset of users" being those who do not need udev before localmount.)
> Citation, please?
>
<ulm> New udev and separate /usr partition
<Chainsaw> In my opinion, a separate /usr partition has been a supported
configuration for a very long time and should remain so.
<Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
<Chainsaw> Betelgeuse: No. That is additional work for a clearly broken
package.
So we must support separate /usr *without* an initramfs.
<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.
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"
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?
The only question is whether running without an initramfs means the same
thing as not requiring udev before localmount. I contend that it is, since
the basic requirement we've been given is that udev as a service requires
/usr and /var mounted before starting, since some devices already require
scripts which are in /usr or access /var (and going forward effectively can
require a script anywhere.)
Wrt udev linking to /usr/lib, it seems that any such linkage would need to
be satisfied in an initramfs too, so the same data could be used for people
who don't have an initramfs (how we deal with it on our systems is up to
us.)
I would dearly love to hear a walkthrough of how you deal with device nodes
created by udev which are required for udev to start in your initramfs, but
it does not affect the basic requirement for our use-case: that udev is not
needed for localmount.
Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 5:28 ` [gentoo-dev] " Steven J Long
@ 2012-04-22 6:00 ` Mike Gilbert
2012-04-22 9:07 ` [gentoo-dev] " Ulrich Mueller
2012-04-22 9:11 ` [gentoo-dev] Re: Re: Re: Re: " Steven J Long
2012-04-23 1:25 ` [gentoo-dev] " Walter Dnes
1 sibling, 2 replies; 111+ messages in thread
From: Mike Gilbert @ 2012-04-22 6:00 UTC (permalink / raw
To: gentoo-dev
On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> Rich Freeman wrote:
>>> The Council has voted that Gentoo continue to support that subset,
>>> without an initramfs.
>>
> (The "subset of users" being those who do not need udev before localmount.)
>
>> Citation, please?
>>
>
> <ulm> New udev and separate /usr partition
> <Chainsaw> In my opinion, a separate /usr partition has been a supported
> configuration for a very long time and should remain so.
> <Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
> <Chainsaw> Betelgeuse: No. That is additional work for a clearly broken
> package.
>
> So we must support separate /usr *without* an initramfs.
>
> <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.
>
> 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"
>
> 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.
You are reading into it more that you should.
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 6:00 ` Mike Gilbert
@ 2012-04-22 9:07 ` Ulrich Mueller
2012-04-22 9:28 ` [gentoo-dev] " Steven J Long
2012-04-22 9:11 ` [gentoo-dev] Re: Re: Re: Re: " Steven J Long
1 sibling, 1 reply; 111+ messages in thread
From: Ulrich Mueller @ 2012-04-22 9:07 UTC (permalink / raw
To: gentoo-dev
>>>>> On Sun, 22 Apr 2012, Mike Gilbert wrote:
> 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.
> You are reading into it more that you should.
Please don't cite single lines without context. My next line in that
log is:
<ulm> as in the agenda
Which says:
| 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>
Ulrich
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 6:00 ` Mike Gilbert
2012-04-22 9:07 ` [gentoo-dev] " Ulrich Mueller
@ 2012-04-22 9:11 ` Steven J Long
1 sibling, 0 replies; 111+ messages in thread
From: Steven J Long @ 2012-04-22 9:11 UTC (permalink / raw
To: gentoo-dev
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 ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 9:07 ` [gentoo-dev] " Ulrich Mueller
@ 2012-04-22 9:28 ` Steven J Long
2012-04-22 17:55 ` Mike Gilbert
0 siblings, 1 reply; 111+ messages in thread
From: Steven J Long @ 2012-04-22 9:28 UTC (permalink / raw
To: gentoo-dev
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 ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 9:28 ` [gentoo-dev] " Steven J Long
@ 2012-04-22 17:55 ` Mike Gilbert
2012-04-22 18:13 ` Zac Medico
2012-05-04 15:10 ` Steven J Long
0 siblings, 2 replies; 111+ messages in thread
From: Mike Gilbert @ 2012-04-22 17:55 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 17:55 ` Mike Gilbert
@ 2012-04-22 18:13 ` Zac Medico
2012-05-04 15:20 ` [gentoo-dev] " Steven J Long
2012-05-04 15:10 ` Steven J Long
1 sibling, 1 reply; 111+ messages in thread
From: Zac Medico @ 2012-04-22 18:13 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 5:28 ` [gentoo-dev] " Steven J Long
2012-04-22 6:00 ` Mike Gilbert
@ 2012-04-23 1:25 ` Walter Dnes
2012-04-23 6:04 ` Zac Medico
` (2 more replies)
1 sibling, 3 replies; 111+ messages in thread
From: Walter Dnes @ 2012-04-23 1:25 UTC (permalink / raw
To: gentoo-dev
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>
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-23 1:25 ` [gentoo-dev] " Walter Dnes
@ 2012-04-23 6:04 ` Zac Medico
2012-04-23 14:29 ` Walter Dnes
2012-04-23 6:30 ` [gentoo-dev] " Fabian Groffen
2012-05-04 14:50 ` [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] " Steven J Long
2 siblings, 1 reply; 111+ messages in thread
From: Zac Medico @ 2012-04-23 6:04 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Council meeting summary for 3 April 2012
2012-04-23 1:25 ` [gentoo-dev] " Walter Dnes
2012-04-23 6:04 ` Zac Medico
@ 2012-04-23 6:30 ` Fabian Groffen
2012-05-04 14:50 ` [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] " Steven J Long
2 siblings, 0 replies; 111+ messages in thread
From: Fabian Groffen @ 2012-04-23 6:30 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-23 6:04 ` Zac Medico
@ 2012-04-23 14:29 ` Walter Dnes
0 siblings, 0 replies; 111+ messages in thread
From: Walter Dnes @ 2012-04-23 14:29 UTC (permalink / raw
To: gentoo-dev
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>
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-11 16:10 ` [gentoo-dev] " Steven J Long
@ 2012-04-28 21:09 ` Mike Frysinger
2012-05-04 16:36 ` [gentoo-dev] " Steven J Long
0 siblings, 1 reply; 111+ messages in thread
From: Mike Frysinger @ 2012-04-28 21:09 UTC (permalink / raw
To: gentoo-dev; +Cc: Steven J Long
[-- Attachment #1: Type: Text/Plain, Size: 1387 bytes --]
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-10 18:45 ` [gentoo-dev] " William Hubbs
2012-04-11 9:34 ` Ralph Sennhauser
@ 2012-04-28 23:44 ` Luca Barbato
2012-04-29 6:44 ` Michał Górny
1 sibling, 1 reply; 111+ messages in thread
From: Luca Barbato @ 2012-04-28 23:44 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-28 23:44 ` Luca Barbato
@ 2012-04-29 6:44 ` Michał Górny
2012-04-29 7:04 ` Luca Barbato
0 siblings, 1 reply; 111+ messages in thread
From: Michał Górny @ 2012-04-29 6:44 UTC (permalink / raw
To: gentoo-dev; +Cc: lu_zero
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
On Sat, 28 Apr 2012 16:44:57 -0700
Luca Barbato <lu_zero@gentoo.org> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-29 6:44 ` Michał Górny
@ 2012-04-29 7:04 ` Luca Barbato
2012-04-29 22:40 ` Zac Medico
0 siblings, 1 reply; 111+ messages in thread
From: Luca Barbato @ 2012-04-29 7:04 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-dev
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
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-29 7:04 ` Luca Barbato
@ 2012-04-29 22:40 ` Zac Medico
2012-04-29 23:38 ` Luca Barbato
0 siblings, 1 reply; 111+ messages in thread
From: Zac Medico @ 2012-04-29 22:40 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-29 22:40 ` Zac Medico
@ 2012-04-29 23:38 ` Luca Barbato
0 siblings, 0 replies; 111+ messages in thread
From: Luca Barbato @ 2012-04-29 23:38 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-23 1:25 ` [gentoo-dev] " Walter Dnes
2012-04-23 6:04 ` Zac Medico
2012-04-23 6:30 ` [gentoo-dev] " Fabian Groffen
@ 2012-05-04 14:50 ` Steven J Long
2012-05-05 1:05 ` Greg KH
2 siblings, 1 reply; 111+ messages in thread
From: Steven J Long @ 2012-05-04 14:50 UTC (permalink / raw
To: gentoo-dev
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 ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 17:55 ` Mike Gilbert
2012-04-22 18:13 ` Zac Medico
@ 2012-05-04 15:10 ` Steven J Long
1 sibling, 0 replies; 111+ messages in thread
From: Steven J Long @ 2012-05-04 15:10 UTC (permalink / raw
To: gentoo-dev
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 ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-22 18:13 ` Zac Medico
@ 2012-05-04 15:20 ` Steven J Long
2012-05-04 19:50 ` Zac Medico
0 siblings, 1 reply; 111+ messages in thread
From: Steven J Long @ 2012-05-04 15:20 UTC (permalink / raw
To: gentoo-dev
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 ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-04-28 21:09 ` Mike Frysinger
@ 2012-05-04 16:36 ` Steven J Long
2012-05-04 16:47 ` Mike Frysinger
0 siblings, 1 reply; 111+ messages in thread
From: Steven J Long @ 2012-05-04 16:36 UTC (permalink / raw
To: gentoo-dev
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 ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-05-04 16:36 ` [gentoo-dev] " Steven J Long
@ 2012-05-04 16:47 ` Mike Frysinger
2012-05-04 17:24 ` [gentoo-dev] " Steven J Long
0 siblings, 1 reply; 111+ messages in thread
From: Mike Frysinger @ 2012-05-04 16:47 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 493 bytes --]
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-05-04 16:47 ` Mike Frysinger
@ 2012-05-04 17:24 ` Steven J Long
0 siblings, 0 replies; 111+ messages in thread
From: Steven J Long @ 2012-05-04 17:24 UTC (permalink / raw
To: gentoo-dev
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 ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-05-04 15:20 ` [gentoo-dev] " Steven J Long
@ 2012-05-04 19:50 ` Zac Medico
0 siblings, 0 replies; 111+ messages in thread
From: Zac Medico @ 2012-05-04 19:50 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
2012-05-04 14:50 ` [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] " Steven J Long
@ 2012-05-05 1:05 ` Greg KH
2012-05-08 1:40 ` [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012] Steven J Long
0 siblings, 1 reply; 111+ messages in thread
From: Greg KH @ 2012-05-05 1:05 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-05 1:05 ` Greg KH
@ 2012-05-08 1:40 ` Steven J Long
2012-05-08 2:09 ` Richard Yao
2012-05-09 18:32 ` Greg KH
0 siblings, 2 replies; 111+ messages in thread
From: Steven J Long @ 2012-05-08 1:40 UTC (permalink / raw
To: gentoo-dev
Greg KH wrote:
> On Fri, May 04, 2012 at 03:50:24PM +0100, Steven J Long wrote:
>> >> To confirm again, that this is about without initramfs:
>> > 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?
<snip>
>> (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"?
>
Yes, in the sense of "raised it as a possibility" or in this case a future
direction[1] as discussed on debian-dev[2].
I'll assume you're just not familiar with the word 'moot' as a verb;
originally the adjective meant 'on the agenda' or 'on the table', and 'to
moot' means to raise an item for discussion. Its modern meaning of 'no
longer worth discussing' comes from the judiciary: for it to be dismissed,
it had to be under discussion in the first place, and so usage evolved.
> 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.
>
When did I say that it's the same thing? I simply said it sounds like "the
same reasoning." Compare:
"There are a number of folk in the Linux ecosystem pushing for a
small core of tightly coupled components to make the core of a modern
linux distro. The idea is that this 'core distro' can evolve in sync
with the kernel, and generally move fast. This is both good for the
overall platform and very hard to implement for the 'universal'
distros [such as Gentoo or Debian]." [1]
..with:
"The future of GNOME is as a Linux based OS. It is harmful to pretend
that you are writing the OS core to work on any number of different
kernels, user space subsystem combinations, and core libraries..
Kernels just aren't that interesting. Linux isn't an OS. Now it is
our job to try to build one - finally. Let's do it."[3]
They sound like very similar reasoning to me. You misinterpreted what I
said, which is one thing: there was no need to be discourteous.
Let me be clear: I don't personally have an issue with udev talking to dbus
(a requirement for it sounds wrong to me, but that's by-the-by.) It would
annoy me no end, however, if udev required systemd, since I don't want to
switch to it. And that is what we were discussing: possible future coupling
between the two, which is much easier to do when the sources are part of the
same package.
Everything I need done on a desktop or a laptop in terms of hotplug, acpid
events and wifi, the current udev has been able to do for years. I'd find it
odd (read: the design smells) if those use-cases suddenly required new
external dependencies. AFAIC vertical integration is supposed to mean closer
downward coupling, typically skipping a layer or two; if it also means
upward coupling, then the design is flawed ime.
*shrug* What you do with your time, is your business. I'll evaluate any
coupling that does or doesn't come up as and when, and make my own decisions
then.
That it's been mooted by you ;) means I'm glad others are doing work on
busybox and mdev integration into openrc (I've read tonight that mdev works
fine for simple hotplug like USB sticks) especially the applet to fsck and
mount /usr early.
OFC you could just assure us that udev will never rely on systemd as a
design decision. I can understand that systemd might need close integration
with the underlying udev implementation[PS].
SteveL.
[1] https://plus.google.com/u/0/111049168280159033135/posts/V2t57Efkf1s
[2] http://lists.debian.org/debian-devel/2012/04/msg00649.html
[3] http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00439.html
[PS] Though it reminds me of packages distributing libraries, and I'd
question why one git repo can't be used to make two tarballs, with beta
testing of udev alone by distros like Gentoo or Debian. A separate tarball
would mean automated tests can be done, which is useful as a basis for
systemd et al: another benefit of no upward coupling.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-08 1:40 ` [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012] Steven J Long
@ 2012-05-08 2:09 ` Richard Yao
2012-05-09 18:32 ` Greg KH
1 sibling, 0 replies; 111+ messages in thread
From: Richard Yao @ 2012-05-08 2:09 UTC (permalink / raw
To: gentoo-dev; +Cc: Steven J Long
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
On 05/07/12 21:40, Steven J Long wrote:
> "The future of GNOME is as a Linux based OS. It is harmful to pretend
> that you are writing the OS core to work on any number of different
> kernels, user space subsystem combinations, and core libraries..
> Kernels just aren't that interesting. Linux isn't an OS. Now it is
> our job to try to build one - finally. Let's do it."[3]
For what it is worth, the OS core is the kernel, libc and bootloader.
GNOME runs on top of that.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-08 1:40 ` [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012] Steven J Long
2012-05-08 2:09 ` Richard Yao
@ 2012-05-09 18:32 ` Greg KH
2012-05-09 18:51 ` Fabio Erculiani
2012-05-17 4:16 ` Steven J Long
1 sibling, 2 replies; 111+ messages in thread
From: Greg KH @ 2012-05-09 18:32 UTC (permalink / raw
To: gentoo-dev
On Tue, May 08, 2012 at 02:40:41AM +0100, Steven J Long wrote:
> OFC you could just assure us that udev will never rely on systemd as a
> design decision. I can understand that systemd might need close integration
> with the underlying udev implementation[PS].
Nope, can't make that assurance at all.
Actually, maybe I can make the opposite assurance, let's see what the
future brings... :)
greg k-h
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-09 18:32 ` Greg KH
@ 2012-05-09 18:51 ` Fabio Erculiani
2012-05-09 22:36 ` Greg KH
` (2 more replies)
2012-05-17 4:16 ` Steven J Long
1 sibling, 3 replies; 111+ messages in thread
From: Fabio Erculiani @ 2012-05-09 18:51 UTC (permalink / raw
To: gentoo-dev
I foresee a new udev fork then.
If udev is going to end up like avahi is, this is *highly* probable.
With "avahi is ..." I actually mean, one single tarball blob depending
on the whole world and its solar system and galaxy.
Please stop throwing lennartware at people. FailAudio has been enough, thanks.
--
Fabio Erculiani
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-09 18:51 ` Fabio Erculiani
@ 2012-05-09 22:36 ` Greg KH
2012-05-10 1:08 ` Patrick Lauer
` (3 more replies)
2012-05-10 19:55 ` [gentoo-dev] " Markos Chandras
[not found] ` <4bdd949a377d40eb85590870be440551@HUBCAS1.cs.stonybrook.edu>
2 siblings, 4 replies; 111+ messages in thread
From: Greg KH @ 2012-05-09 22:36 UTC (permalink / raw
To: gentoo-dev
On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
> I foresee a new udev fork then.
Please feel free to do so, the code has been open since the first day I
created it.
Remember, forks are good, there's nothing wrong with them, I strongly
encourage people to do them if they wish to, it benefits everyone
involved.
> If udev is going to end up like avahi is, this is *highly* probable.
That's an odd transition...
> With "avahi is ..." I actually mean, one single tarball blob depending
> on the whole world and its solar system and galaxy.
Hyperbole, how nice :(
> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
The use of these terms is both rude and totally uncalled for. You
should be ashamed of yourself.
Seriously, that's unacceptable behavior from anyone.
No one forces you to use any of this software if you do not want to.
There are lots of other operating systems out there, feel free to switch
to them if you do not like the way this one is working out, no one is
stopping you. But for you to disparage someone who has given immense
bodies of work to the community, and you, for free, is horrible behavior
and needs to stop right now.
greg k-h
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-09 22:36 ` Greg KH
@ 2012-05-10 1:08 ` Patrick Lauer
2012-05-10 3:08 ` Rich Freeman
2012-05-10 4:34 ` Fabio Erculiani
` (2 subsequent siblings)
3 siblings, 1 reply; 111+ messages in thread
From: Patrick Lauer @ 2012-05-10 1:08 UTC (permalink / raw
To: gentoo-dev
On 05/10/12 06:36, Greg KH wrote:
> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>> I foresee a new udev fork then.
> Please feel free to do so, the code has been open since the first day I
> created it.
>
> Remember, forks are good, there's nothing wrong with them, I strongly
> encourage people to do them if they wish to, it benefits everyone
> involved.
Forks are often unnecessary.
Now instead of working on something useful I get to spend my time
reverting to previous behaviour, just so I can have a working solution
instead of a shiny one.
Are we really doing so well that we can just rewrite everything instead
of maybe, for once, have things boring predictable and bugfree? I mean
... things were going so well. Machines Just Booted Every TIme.
And now - UEFI is glitching all over the place, the GPT-aware
bootloaders have config files with insane complexity and are exquisitely
buggy, and someone thought making the init system exciting would just
make life oh so much better. Result: I can't get more than a blinking
cursor out of some machines without resorting to Dirty Hacks I would
really prefer not to even consider.
Seriously. I don't have time for these games. Stop breaking stuff!
>
>> If udev is going to end up like avahi is, this is *highly* probable.
> That's an odd transition...
Same people involved, same mentality - and we don't want to be standing
on the sides saying "Told you so" again. Gets boring.
>
>> With "avahi is ..." I actually mean, one single tarball blob depending
>> on the whole world and its solar system and galaxy.
> Hyperbole, how nice :(
>
>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
> The use of these terms is both rude and totally uncalled for. You
> should be ashamed of yourself.
It's reactive. I've been called stupid, conservative, behind the times,
user of obsolete software that will go the way of the dinosaurs. Why
should we be ashamed of not agreeing with these funny pranksters?
>
> Seriously, that's unacceptable behavior from anyone.
Then make it stop? :)
>
> No one forces you to use any of this software if you do not want to.
Yeah, I can just stop updating. Sounds like a solution to all problems ;)
> There are lots of other operating systems out there, feel free to switch
> to them if you do not like the way this one is working out, no one is
> stopping you. But for you to disparage someone who has given immense
> bodies of work to the community, and you, for free, is horrible behavior
> and needs to stop right now.
Goes both ways. We're here because of Freedom, in various flavours.
Freedom to copy things around and use for free. Freedom to swap out one
part and use another.
Freedom to break things badly.
So why would I give up my freedom to tinker just because someone else is
writing more code than I do?
And I still have the freedom to complain all day long about undesigned
stuff people try to force on me.
Hey, you even have the freedom to complain about my complaining.
Either way, I hope I can continue using Free Linux for a while and not
be forced to use random things that are silly. I'd have expected you to
support that.
Take care,
Patrick
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 1:08 ` Patrick Lauer
@ 2012-05-10 3:08 ` Rich Freeman
0 siblings, 0 replies; 111+ messages in thread
From: Rich Freeman @ 2012-05-10 3:08 UTC (permalink / raw
To: gentoo-dev
On Wed, May 9, 2012 at 9:08 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 05/10/12 06:36, Greg KH wrote:
>> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
>> The use of these terms is both rude and totally uncalled for. You
>> should be ashamed of yourself.
> It's reactive. I've been called stupid, conservative, behind the times,
> user of obsolete software that will go the way of the dinosaurs. Why
> should we be ashamed of not agreeing with these funny pranksters?
Look, I have pretty mixed feelings about all the vertical integration.
However, let's at least do each other the professional courtesy of
not resorting to name-calling. We're allowed to disagree, and that's
OK. By all means voice your opinion. However, let's talk about the
issues, and not the people advocating them.
This is just polite behavior. It is also the rules for posting on
this list, especially if you hold a g.o address.
> So why would I give up my freedom to tinker just because someone else is
> writing more code than I do?
I understand your frustration. Really, I do - I often find myself
sharing it. However, in the end people working on FOSS are basically
free to do what they want, and everybody is free to use or support
what they want. I don't like the fact that most people contributing
to Android tend/aspire to be associated with the commercial market for
smartphones, and as a result they tend to embrace pro-developer /
anti-consumer solutions (like not allowing easy blocking of ads, or
randomizing calls to read the IMEI, etc). However, the market is what
it is. The only thing that is really any different today is that
companies are at least releasing the source for the stuff they do - in
the past they'd have just closed it all off so that there wouldn't
even be the option of forking. If I want to I can at least find the
API call to read my IMEI and tamper with it.
I think part of the community frustration is the increasing level of
commercial support around Linux. That has given us much more robust
stuff to play with, but it also has resulted in a loss of control and
change in general atmosphere. In the world of 1999 Linux market share
took a back seat to hackability. In the world of the Canonicals,
market share matters a great deal, and appealing to open source
contributors matters a lot less.
Rich
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-09 22:36 ` Greg KH
2012-05-10 1:08 ` Patrick Lauer
@ 2012-05-10 4:34 ` Fabio Erculiani
2012-05-10 16:54 ` Olivier Crête
2012-05-10 23:41 ` Alec Warner
2012-05-10 11:44 ` [gentoo-dev] " Chí-Thanh Christopher Nguyễn
2012-05-10 18:57 ` David Leverton
3 siblings, 2 replies; 111+ messages in thread
From: Fabio Erculiani @ 2012-05-10 4:34 UTC (permalink / raw
To: gentoo-dev
I think expressing my own opinion about Lennart-made software is my
right, after all.
Firstly, it's almost impossible nowadays to avoid including avahi,
systemd and pulseaudio into a desktop distro so, there is no real
choice. This issue became a sensible matter for those users who for
instance, wanted to have a silly mp3 player working without going
through the PA nonsense, really missing the old
ALSA-oh-it-was-always-working days.
If you want to bring complexity but you end up not being able to
handle it, then you're not a really good engineer, IMHO.
Having said that, I also wonder where's the lovely modularity the
various *nix platforms had. If this is the actual direction of Linux
Foundation, Redhat and Canonical, I am worried that Linux would end up
being an OSX-wannabe.
Of course, I am not only bringing my personal opinion here, but the
one of the majority of users I've been talking with.
I am not against changes, I am actually in favor of them, but only
when they really make sense and solve problems, which it doesn't seem
the case lately.
I didn't want to offend anyone, but just having fun (sigh) of IMHO bad
design decisions.
--
Fabio Erculiani
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-09 22:36 ` Greg KH
2012-05-10 1:08 ` Patrick Lauer
2012-05-10 4:34 ` Fabio Erculiani
@ 2012-05-10 11:44 ` Chí-Thanh Christopher Nguyễn
2012-05-10 14:39 ` Zac Medico
2012-05-12 0:39 ` Greg KH
2012-05-10 18:57 ` David Leverton
3 siblings, 2 replies; 111+ messages in thread
From: Chí-Thanh Christopher Nguyễn @ 2012-05-10 11:44 UTC (permalink / raw
To: gentoo-dev
Greg KH schrieb:
> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
> The use of these terms is both rude and totally uncalled for. You
> should be ashamed of yourself.
>
> Seriously, that's unacceptable behavior from anyone.
You mean as unacceptable as calling C++ proponents "full of
bullshit"[1], developers of another operating system "masturbating
monkeys"[2] and security researchers as "people wanking around with
their opinions"[3]?
> No one forces you to use any of this software if you do not want to.
> There are lots of other operating systems out there, feel free to switch
> to them if you do not like the way this one is working out, no one is
> stopping you. But for you to disparage someone who has given immense
> bodies of work to the community, and you, for free, is horrible behavior
> and needs to stop right now.
Insulting other people is indeed not nice. A borderline statement would
be the "card-carrying member of the Poettering gang" which was coined by
a well-known kernel developer who shall remain unnamed here.
But using harsh words to describe other people's software? C'mon.
Best regards,
Chí-Thanh Christopher Nguyễn
[1] http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
[2] https://lkml.org/lkml/2008/7/15/296
[3] https://lkml.org/lkml/2007/10/1/217
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 11:44 ` [gentoo-dev] " Chí-Thanh Christopher Nguyễn
@ 2012-05-10 14:39 ` Zac Medico
2012-05-12 0:39 ` Greg KH
1 sibling, 0 replies; 111+ messages in thread
From: Zac Medico @ 2012-05-10 14:39 UTC (permalink / raw
To: gentoo-dev
On 05/10/2012 04:44 AM, Chí-Thanh Christopher Nguyễn wrote:
> Greg KH schrieb:
>> No one forces you to use any of this software if you do not want to.
>> There are lots of other operating systems out there, feel free to switch
>> to them if you do not like the way this one is working out, no one is
>> stopping you. But for you to disparage someone who has given immense
>> bodies of work to the community, and you, for free, is horrible behavior
>> and needs to stop right now.
>
> Insulting other people is indeed not nice. A borderline statement would
> be the "card-carrying member of the Poettering gang" which was coined by
> a well-known kernel developer who shall remain unnamed here.
> But using harsh words to describe other people's software? C'mon.
Specific criticism's can be be constructive, but calling PulseAudio a
name like FailAudio certainly isn't. I'd enjoy reading this thread a lot
more if it contained more discussion about solutions, and less of what
seems like whining due to self-pity.
--
Thanks,
Zac
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 4:34 ` Fabio Erculiani
@ 2012-05-10 16:54 ` Olivier Crête
2012-05-14 18:48 ` Luca Barbato
2012-05-10 23:41 ` Alec Warner
1 sibling, 1 reply; 111+ messages in thread
From: Olivier Crête @ 2012-05-10 16:54 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]
Hi,
On Thu, 2012-05-10 at 06:34 +0200, Fabio Erculiani wrote:
> I think expressing my own opinion about Lennart-made software is my
> right, after all.
I would express my opinion about Fabio made software, but I've never
heard of any.
> Firstly, it's almost impossible nowadays to avoid including avahi,
> systemd and pulseaudio into a desktop distro so, there is no real
> choice. This issue became a sensible matter for those users who for
> instance, wanted to have a silly mp3 player working without going
> through the PA nonsense, really missing the old
> ALSA-oh-it-was-always-working days.
Maybe the reason every sensible distribution uses Avahi, Pulseaudio, etc
is because they are better than other solutions out there?
Do you think is a fast conspiracy to make your life suck? I believe
engineers in every distribution are looking at what's available and
picking what they think is the best solution, and it turns out Lennart
is pretty damn good at making useful software.
Was alsa always working? I remember spending hours trying to figure out
the right control in alsamixer and fighting with alsa's arcane
configuration languages (it has 3 different ones). And how do you deal
with modern technologies like Bluetooth audio without Pulseaudio
exactly?
> Of course, I am not only bringing my personal opinion here, but the
> one of the majority of users I've been talking with.
I think you only hear from users who like to complain, others are just
happy that everything works for them thanks to Pulseaudio, systemd, etc.
If you think that Lennart does not solve problems, maybe it's because
you don't even understand what the problems were? For example, I
encourage you to read about how the dynamic latency in PA allows for
lower power usage or how modern audio hardware is designed to use a
userspace sound server, etc.
--
Olivier Crête
tester@gentoo.org
Gentoo Developer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-09 22:36 ` Greg KH
` (2 preceding siblings ...)
2012-05-10 11:44 ` [gentoo-dev] " Chí-Thanh Christopher Nguyễn
@ 2012-05-10 18:57 ` David Leverton
2012-05-10 19:22 ` Zac Medico
2012-05-11 1:27 ` [gentoo-dev] " Duncan
3 siblings, 2 replies; 111+ messages in thread
From: David Leverton @ 2012-05-10 18:57 UTC (permalink / raw
To: gentoo-dev
Greg KH wrote:
> No one forces you to use any of this software if you do not want to.
> There are lots of other operating systems out there, feel free to switch
> to them if you do not like the way this one is working out, no one is
> stopping you.
Or alternatively, the people who hate Unix could move to some other OS
that suites them better, rather than trying to destroy what everyone
else is perfectly happy with.
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 18:57 ` David Leverton
@ 2012-05-10 19:22 ` Zac Medico
2012-05-10 19:30 ` David Leverton
2012-05-11 1:27 ` [gentoo-dev] " Duncan
1 sibling, 1 reply; 111+ messages in thread
From: Zac Medico @ 2012-05-10 19:22 UTC (permalink / raw
To: gentoo-dev
On 05/10/2012 11:57 AM, David Leverton wrote:
> Greg KH wrote:
>> No one forces you to use any of this software if you do not want to.
>> There are lots of other operating systems out there, feel free to switch
>> to them if you do not like the way this one is working out, no one is
>> stopping you.
>
> Or alternatively, the people who hate Unix could move to some other OS
> that suites them better, rather than trying to destroy what everyone
> else is perfectly happy with.
Isn't it presumptuous to say that they hate Unix? Maybe their vision of
how they'd like Unix to be is just different from yours?
--
Thanks,
Zac
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 19:22 ` Zac Medico
@ 2012-05-10 19:30 ` David Leverton
0 siblings, 0 replies; 111+ messages in thread
From: David Leverton @ 2012-05-10 19:30 UTC (permalink / raw
To: gentoo-dev
Zac Medico wrote:
> Isn't it presumptuous to say that they hate Unix? Maybe their vision of
> how they'd like Unix to be is just different from yours?
If "how they'd like Unix to be" goes so blatantly against its
fundamental design principles then I think it's reasonable to say that
they hate it.
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-09 18:51 ` Fabio Erculiani
2012-05-09 22:36 ` Greg KH
@ 2012-05-10 19:55 ` Markos Chandras
2012-05-10 19:59 ` Ciaran McCreesh
2012-05-10 20:48 ` Fabio Erculiani
[not found] ` <4bdd949a377d40eb85590870be440551@HUBCAS1.cs.stonybrook.edu>
2 siblings, 2 replies; 111+ messages in thread
From: Markos Chandras @ 2012-05-10 19:55 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 05/09/2012 07:51 PM, Fabio Erculiani wrote:
> I foresee a new udev fork then. If udev is going to end up like
> avahi is, this is *highly* probable.
>
> With "avahi is ..." I actually mean, one single tarball blob
> depending on the whole world and its solar system and galaxy.
>
> Please stop throwing lennartware at people. FailAudio has been
> enough, thanks.
I sincerely hope someone has "hacked" into your account and he is
writing on your behalf. This sort of trash talk does not belong to a
public Gentoo mailing list. Make a constructive criticism if you
really need to rant about software that nobody forces you to use.
- --
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAEBCgAGBQJPrB0WAAoJEPqDWhW0r/LCFGYQAJiKzJ6RUYrkCswRBeWFk9Vn
6kOybbC9nn8LgQuoSjlNXWQ2jm5qqYEWhwzmFJMaeYJ7vpaVNL9nDTslloiXiw46
2dEjBUyXzmx90VIAvAvos3lec2C45vHXUYwjCp8VfwIfL+syPfb0wIXIn+RETAHg
2c4vyPRvv145zCPRkdF/b0GV4ai6JozRTrUOn2dobEs2SaqadqY4cw5uj1P47Msd
Jezdz4MaPUPf16q0CoK6yi4U0jkzEqGtJbinHT4ib9PMhYX8WXjJtLloaBiQk01l
bKNJWOAMIEpWK6dD2rko5pY4igS9ccbFCLlEDnELQBSHXDGAmarmGRlN6C/qVasY
019n3fSUsLt+kMeH2WgfmmXViyBgPeQxMY0E4HVkV+ztwNp3by8gG3jtuQeX+Kij
WaECR/2/DwUTU+kLLkkEa2FZSrg8xwG3Ty5SpCAVQWcJIn3L1tziD58kt1DtpJjs
jt0bV1eT2JnxL4v7GopxUI55n4bmqqzRP7SebkK4B7AOlae1fxjukqpNC6s6oTgc
CBoWiJ7DkRbcTk+ww+MF+xUCmYrqPFlf8aQ8+j16LogaTCeV09QIhAqUKkcQB8Lx
k6gGD6H5elPsYDm1gP/wBe1WEe6zLXDLd6LFiEYKHjyiznGDs1BAEk0oJMbob5I3
HbAYiBP8P7D7FBosO7oj
=INQn
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 19:55 ` [gentoo-dev] " Markos Chandras
@ 2012-05-10 19:59 ` Ciaran McCreesh
2012-05-10 20:13 ` Michał Górny
2012-05-10 20:48 ` Fabio Erculiani
1 sibling, 1 reply; 111+ messages in thread
From: Ciaran McCreesh @ 2012-05-10 19:59 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 10 May 2012 20:55:02 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:
> Make a constructive criticism if you really need to rant about
> software that nobody forces you to use.
Not that I agree with anything Fabio has ever said, but I believe the
issue under discussion here is that tight coupling and vertical
integration means we are in effect forced to use rather a lot of
software that we would prefer not to.
- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAk+sHi8ACgkQ96zL6DUtXhGZoQCeN5o15CIzO0xJTCNkOW9EhPoc
rjgAoL5WoPQpcxRhceifxFkfecZg5YqK
=+nyf
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 19:59 ` Ciaran McCreesh
@ 2012-05-10 20:13 ` Michał Górny
2012-05-10 20:14 ` Ciaran McCreesh
0 siblings, 1 reply; 111+ messages in thread
From: Michał Górny @ 2012-05-10 20:13 UTC (permalink / raw
To: gentoo-dev; +Cc: ciaran.mccreesh
[-- Attachment #1: Type: text/plain, Size: 750 bytes --]
On Thu, 10 May 2012 20:59:40 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 10 May 2012 20:55:02 +0100
> Markos Chandras <hwoarang@gentoo.org> wrote:
> > Make a constructive criticism if you really need to rant about
> > software that nobody forces you to use.
>
> Not that I agree with anything Fabio has ever said, but I believe the
> issue under discussion here is that tight coupling and vertical
> integration means we are in effect forced to use rather a lot of
> software that we would prefer not to.
No, I don't think you are forced to use anything. As was proven before,
there are always alternatives.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 20:13 ` Michał Górny
@ 2012-05-10 20:14 ` Ciaran McCreesh
2012-05-10 20:23 ` Michał Górny
0 siblings, 1 reply; 111+ messages in thread
From: Ciaran McCreesh @ 2012-05-10 20:14 UTC (permalink / raw
To: Michał Górny; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
On Thu, 10 May 2012 22:13:33 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > On Thu, 10 May 2012 20:55:02 +0100
> > Markos Chandras <hwoarang@gentoo.org> wrote:
> > > Make a constructive criticism if you really need to rant about
> > > software that nobody forces you to use.
> >
> > Not that I agree with anything Fabio has ever said, but I believe
> > the issue under discussion here is that tight coupling and vertical
> > integration means we are in effect forced to use rather a lot of
> > software that we would prefer not to.
>
> No, I don't think you are forced to use anything. As was proven
> before, there are always alternatives.
That's a somewhat disingenuous claim when the alternatives are moving
steadily towards "don't use Linux at all" or "use the full GnomeOS
stack".
--
Ciaran McCreesh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 20:14 ` Ciaran McCreesh
@ 2012-05-10 20:23 ` Michał Górny
0 siblings, 0 replies; 111+ messages in thread
From: Michał Górny @ 2012-05-10 20:23 UTC (permalink / raw
To: gentoo-dev; +Cc: ciaran.mccreesh
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
On Thu, 10 May 2012 21:14:33 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 10 May 2012 22:13:33 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > On Thu, 10 May 2012 20:55:02 +0100
> > > Markos Chandras <hwoarang@gentoo.org> wrote:
> > > > Make a constructive criticism if you really need to rant about
> > > > software that nobody forces you to use.
> > >
> > > Not that I agree with anything Fabio has ever said, but I believe
> > > the issue under discussion here is that tight coupling and
> > > vertical integration means we are in effect forced to use rather
> > > a lot of software that we would prefer not to.
> >
> > No, I don't think you are forced to use anything. As was proven
> > before, there are always alternatives.
>
> That's a somewhat disingenuous claim when the alternatives are moving
> steadily towards "don't use Linux at all" or "use the full GnomeOS
> stack".
Then go rant upstream about it. Or another upstream. Or do something
useful yourself.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 19:55 ` [gentoo-dev] " Markos Chandras
2012-05-10 19:59 ` Ciaran McCreesh
@ 2012-05-10 20:48 ` Fabio Erculiani
2012-05-11 0:59 ` [gentoo-dev] " Duncan
1 sibling, 1 reply; 111+ messages in thread
From: Fabio Erculiani @ 2012-05-10 20:48 UTC (permalink / raw
To: gentoo-dev
On Thu, May 10, 2012 at 9:55 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
> I sincerely hope someone has "hacked" into your account and he is
> writing on your behalf. This sort of trash talk does not belong to a
> public Gentoo mailing list. Make a constructive criticism if you
> really need to rant about software that nobody forces you to use.
No, this was really me. Forgive me for the rant, but the problem here
is real and no, the alternative would be either giving up with the
Linux stack or living with unreliable, overengineered software. I
don't see any other viable alternative.
Just answer my question, what is going to happen the day udev will
require systemd in order to work properly?
On a side note, I find it quite odd to be accused of trash talking by
Linux Kernel people.
>
> - --
> Regards,
> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iQIcBAEBCgAGBQJPrB0WAAoJEPqDWhW0r/LCFGYQAJiKzJ6RUYrkCswRBeWFk9Vn
> 6kOybbC9nn8LgQuoSjlNXWQ2jm5qqYEWhwzmFJMaeYJ7vpaVNL9nDTslloiXiw46
> 2dEjBUyXzmx90VIAvAvos3lec2C45vHXUYwjCp8VfwIfL+syPfb0wIXIn+RETAHg
> 2c4vyPRvv145zCPRkdF/b0GV4ai6JozRTrUOn2dobEs2SaqadqY4cw5uj1P47Msd
> Jezdz4MaPUPf16q0CoK6yi4U0jkzEqGtJbinHT4ib9PMhYX8WXjJtLloaBiQk01l
> bKNJWOAMIEpWK6dD2rko5pY4igS9ccbFCLlEDnELQBSHXDGAmarmGRlN6C/qVasY
> 019n3fSUsLt+kMeH2WgfmmXViyBgPeQxMY0E4HVkV+ztwNp3by8gG3jtuQeX+Kij
> WaECR/2/DwUTU+kLLkkEa2FZSrg8xwG3Ty5SpCAVQWcJIn3L1tziD58kt1DtpJjs
> jt0bV1eT2JnxL4v7GopxUI55n4bmqqzRP7SebkK4B7AOlae1fxjukqpNC6s6oTgc
> CBoWiJ7DkRbcTk+ww+MF+xUCmYrqPFlf8aQ8+j16LogaTCeV09QIhAqUKkcQB8Lx
> k6gGD6H5elPsYDm1gP/wBe1WEe6zLXDLd6LFiEYKHjyiznGDs1BAEk0oJMbob5I3
> HbAYiBP8P7D7FBosO7oj
> =INQn
> -----END PGP SIGNATURE-----
>
--
Fabio Erculiani
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 4:34 ` Fabio Erculiani
2012-05-10 16:54 ` Olivier Crête
@ 2012-05-10 23:41 ` Alec Warner
2012-05-17 4:39 ` [gentoo-dev] " Steven J Long
1 sibling, 1 reply; 111+ messages in thread
From: Alec Warner @ 2012-05-10 23:41 UTC (permalink / raw
To: gentoo-dev
On Thu, May 10, 2012 at 6:34 AM, Fabio Erculiani <lxnay@gentoo.org> wrote:
> I think expressing my own opinion about Lennart-made software is my
> right, after all.
> Firstly, it's almost impossible nowadays to avoid including avahi,
> systemd and pulseaudio into a desktop distro so, there is no real
> choice. This issue became a sensible matter for those users who for
> instance, wanted to have a silly mp3 player working without going
> through the PA nonsense, really missing the old
> ALSA-oh-it-was-always-working days.
Er, the source is open, so choice is always there. What I think your
complaint is the fact that it used to be easy to do those things
(because upstream supported those options and USE flags exposed them
to you) and now upstream is not supporting those options and there is
no easy way to remove the dependencies without doing a bunch of work.
> If you want to bring complexity but you end up not being able to
> handle it, then you're not a really good engineer, IMHO.
I don't think anyone expects complexity to come bug-free. Cathedral
and the Bazaar? Release Early and Release Often? I expect the software
to reach a stable state in a reasonable amount of time given the
complexity involved.
>
> Having said that, I also wonder where's the lovely modularity the
> various *nix platforms had. If this is the actual direction of Linux
> Foundation, Redhat and Canonical, I am worried that Linux would end up
> being an OSX-wannabe.
The problem as I understand it is that you want other people to write
software that meets your needs and it turns out that the world doesn't
always work that way.
You can fork the software you hate (using versions before you hated
it) or you can write your own software (like mdev + busybox) to
replace the hated components. Both of those things are actually
somewhat useful. Complaining about how some random people on the
internet don't write software that you find palatable is just silly.
> Of course, I am not only bringing my personal opinion here, but the
> one of the majority of users I've been talking with.
> I am not against changes, I am actually in favor of them, but only
> when they really make sense and solve problems, which it doesn't seem
> the case lately.
>
> I didn't want to offend anyone, but just having fun (sigh) of IMHO bad
> design decisions.
> --
> Fabio Erculiani
>
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 20:48 ` Fabio Erculiani
@ 2012-05-11 0:59 ` Duncan
2012-05-11 2:53 ` Duncan
2012-05-13 2:24 ` Walter Dnes
0 siblings, 2 replies; 111+ messages in thread
From: Duncan @ 2012-05-11 0:59 UTC (permalink / raw
To: gentoo-dev
Fabio Erculiani posted on Thu, 10 May 2012 22:48:29 +0200 as excerpted:
> On a side note, I find it quite odd to be accused of trash talking by
> Linux Kernel people.
hwoarang is a kernel person?
If you note, gregkh didn't post that. I can't agree with udev/systemd
integration, but it's worth noting that gregkh has for the most part
stayed out of that debate, and simply stated where he sees udev going, as
an upstream person who thus speaks with authority on the subject.
It may very well be that a fork is thus required. I guess we wait and
see. But I don't see the kde folks being willingly subsumed into a
gnomeos black hole, and time and again, floss history has demonstrated
that when there's an immediate need, forks do occur. Both gnome and kde
have their forks in recent history, xorg is a fork, there's the glibc and
gcc history, etc. If integration gets too close, a fork /will/ happen.
But that history is available to everyone and the wise will take heed.
Meanwhile, for the moment at least, upstream udev and systemd have both
taken pains to state that while they're going to ship in a unified
tarball, at least for now, udev will remain buildable on its own,
SPECIFICALLY to support folks not ready to go systemd just yet. So
there's still hope.
And 3-5 years is an eternity in an ecosystem such as the FLOSS world,
evolving at the speed of the net! Looking back from there, it's quite
possible this debate will look petty and short-sighted, regardless of how
things ultimately turn out.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 18:57 ` David Leverton
2012-05-10 19:22 ` Zac Medico
@ 2012-05-11 1:27 ` Duncan
1 sibling, 0 replies; 111+ messages in thread
From: Duncan @ 2012-05-11 1:27 UTC (permalink / raw
To: gentoo-dev
David Leverton posted on Thu, 10 May 2012 19:57:30 +0100 as excerpted:
> Greg KH wrote:
>> No one forces you to use any of this software if you do not want to.
>> There are lots of other operating systems out there, feel free to
>> switch to them if you do not like the way this one is working out, no
>> one is stopping you.
>
> Or alternatively, the people who hate Unix could move to some other OS
> that suites them better, rather than trying to destroy what everyone
> else is perfectly happy with.
I see the "hate Unix" angle tho I'd call it a bit strong...
But trying to destroy what everyone else is perfectly happy with??
How is simply writing some software, which after all is FLOSS and which
nobody is forced to use, "destroying"? They're taking their own software
where their vision points it, no more, no less. I don't really agree
with where it's going either, but that's part of the very freedom of the
FLOSS community we're all a part of. Others can fork the software or
provide less integrated substitutes, if desired. Meanwhile, if it's what
other coders choose to build on, well, they're free to do that too. It
doesn't mean I have to use their software!
FWIW, that's one reason I'm no longer using kmail, for instance. When
kmail akonadified, I tried it, then switched to claws-mail. It's ALSO one
reason I'm using gentoo, I get to choose whether I build kde with akonadi
and semantic-desktop support, or not. And I choose not. I see the kdepim
folks vision, and they're free to pursue it, but their path and my path
simply diverged, that's all. Kde runs SO much nicer without the weight
of semantic-desktop dragging it down.
And if the systemd and udev path fully merge, I'll have a choice at that
point. If systemd looks mature and stable enough at that point to be
used on my system, I'll probably try it. I might like it. =:^) Or, like
akonadified kmail, I may find it a rube goldberg of a system that I'd
rather stay away from. Given history, I'm sure there will be alternate
solutions available, tho it'll no doubt take some serious work and
adaptation on my part to switch.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-11 0:59 ` [gentoo-dev] " Duncan
@ 2012-05-11 2:53 ` Duncan
2012-05-13 2:24 ` Walter Dnes
1 sibling, 0 replies; 111+ messages in thread
From: Duncan @ 2012-05-11 2:53 UTC (permalink / raw
To: gentoo-dev
Duncan posted on Fri, 11 May 2012 00:59:22 +0000 as excerpted:
> Fabio Erculiani posted on Thu, 10 May 2012 22:48:29 +0200 as excerpted:
>
>> On a side note, I find it quite odd to be accused of trash talking by
>> Linux Kernel people.
>
> hwoarang is a kernel person?
FWIW, I see the gregkh post you were referring to, now. Odd indeed, tho
he just said rude, not trash talk.
FWIW2, I'd have probably included a "IME" (in my experience) disclaimer
to that failaudio, tho I don't disagree with that label. Toning down may
be worthwhile for all sides, tho. This isn't lkml and I don't think most
would want it to be.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 11:44 ` [gentoo-dev] " Chí-Thanh Christopher Nguyễn
2012-05-10 14:39 ` Zac Medico
@ 2012-05-12 0:39 ` Greg KH
1 sibling, 0 replies; 111+ messages in thread
From: Greg KH @ 2012-05-12 0:39 UTC (permalink / raw
To: gentoo-dev
On Thu, May 10, 2012 at 01:44:53PM +0200, Chí-Thanh Christopher Nguyễn wrote:
> Greg KH schrieb:
> > On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
> >> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
> > The use of these terms is both rude and totally uncalled for. You
> > should be ashamed of yourself.
> >
> > Seriously, that's unacceptable behavior from anyone.
>
> You mean as unacceptable as calling C++ proponents "full of
> bullshit"[1], developers of another operating system "masturbating
> monkeys"[2] and security researchers as "people wanking around with
> their opinions"[3]?
Did I say any of that?
I have no idea why you are comparing me to anyone else. Who ever said
that those links are acceptable behavior either? I never did.
greg k-h
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-11 0:59 ` [gentoo-dev] " Duncan
2012-05-11 2:53 ` Duncan
@ 2012-05-13 2:24 ` Walter Dnes
1 sibling, 0 replies; 111+ messages in thread
From: Walter Dnes @ 2012-05-13 2:24 UTC (permalink / raw
To: gentoo-dev
On Fri, May 11, 2012 at 12:59:22AM +0000, Duncan wrote
> It may very well be that a fork is thus required. I guess we wait and
> see. But I don't see the kde folks being willingly subsumed into a
> gnomeos black hole, and time and again, floss history has demonstrated
> that when there's an immediate need, forks do occur. Both gnome and kde
> have their forks in recent history, xorg is a fork, there's the glibc and
> gcc history, etc. If integration gets too close, a fork /will/ happen.
There already is a lightweight udev implementation ("mdev") included
in busybox. Given busybox's philisophy and goals, we can be certain
that mdev will remain lightweight. I'm not a programmer or developer,
but I was annoyed enough to start what became
https://wiki.gentoo.org/wiki/Mdev BTW, there is a sort of "udev rules"
equivalant. See http://git.busybox.net/busybox/plain/docs/mdev.txt
--
Walter Dnes <waltdnes@waltdnes.org>
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 16:54 ` Olivier Crête
@ 2012-05-14 18:48 ` Luca Barbato
0 siblings, 0 replies; 111+ messages in thread
From: Luca Barbato @ 2012-05-14 18:48 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/05/12 09:54, Olivier Crête wrote:
> Hi,
>
> On Thu, 2012-05-10 at 06:34 +0200, Fabio Erculiani wrote:
>> I think expressing my own opinion about Lennart-made software is my
>> right, after all.
>
> I would express my opinion about Fabio made software, but I've never
> heard of any.
Not his fault, he wrote plenty of interesting stuff though.
Fabio attitude still isn't that horrible regarding feedbacks, Rigo got
created more or less because the previous UI got a sound "it sucks".
His quite short and a bit extreme reaction probably is due having lots
of unhappy user complaining at him for some issue with avahi (hangs in
bonjour now and then) and pulse (skype freezing randomly anyone).
>> Firstly, it's almost impossible nowadays to avoid including avahi,
>> systemd and pulseaudio into a desktop distro so, there is no real
>> choice. This issue became a sensible matter for those users who for
>> instance, wanted to have a silly mp3 player working without going
>> through the PA nonsense, really missing the old
>> ALSA-oh-it-was-always-working days.
>
> Maybe the reason every sensible distribution uses Avahi, Pulseaudio, etc
> is because they are better than other solutions out there?
If there are solutions somebody will use them, if people are aware of
them and doesn't get too hard. I did like the concept about pulse and
even wrote support for pulse in a certain fringe software you might use.
The pulse concept is quite good, some corner cases and some design
issues make it annoying at time. The fact some of them are consider
"features" or "design" obviously make the whole thing less nice.
> Do you think is a fast conspiracy to make your life suck? I believe
> engineers in every distribution are looking at what's available and
> picking what they think is the best solution, and it turns out Lennart
> is pretty damn good at making useful software.
No, he is pretty damn good in getting interesting concepts, having
people sold on them and then you need 5 years to have the audio seldom
crash, bonjour seldom kill pidgin and so on.
Till it is some minor annoyance that is comparable to not having the
feature or the same to other feature provider (dmix isn't exactly great
as well) you surely can live with it.
> Was alsa always working? I remember spending hours trying to figure out
> the right control in alsamixer and fighting with alsa's arcane
> configuration languages (it has 3 different ones). And how do you deal
> with modern technologies like Bluetooth audio without Pulseaudio
> exactly?
I used to do that and it was working sort of fine even if it was
crashing in dbus...
>> Of course, I am not only bringing my personal opinion here, but the
>> one of the majority of users I've been talking with.
>
> I think you only hear from users who like to complain, others are just
> happy that everything works for them thanks to Pulseaudio, systemd, etc.
As said, if they are minor annoyances most people would just cope with them.
A - "Skype hangs because pulse? oh well, let's reload it no biggie"
B - "AAaargh I missed the important confcall because #%$#@ skype hang
due pulse, I hate YOU Lennart!"
A and B are different reactions from the same small issue.
> If you think that Lennart does not solve problems, maybe it's because
> you don't even understand what the problems were? For example, I
> encourage you to read about how the dynamic latency in PA allows for
> lower power usage or how modern audio hardware is designed to use a
> userspace sound server, etc.
I recall when the whole thing got initially reported and it was "pulse
eats my batter" and if you consider that the stock pulse on ubuntu
oneric eats about a *least* 10% cpu on imx51 due funny resampling loops
you know something needed some more attention. I guess I'm digressing.
The main issue is that udev best replacement so far is mdev plus some
additional helpers to let applications using libudev or the dbus
interface still get compatibility.
So having udev merge with systemd is quite in the shovel meet throat side.
People that had and have some bad experience with pulse and avahi or
directly with Lennart stubborn and abrasive personality can be *quite*
concerned about this "vertical" and linux-only approach.
If you consider that in 2 weeks the whole thing went from "udev moves to
systemd since is easier for us, but not be concerned udev can build
stand alone" to "udev stand alone is unsupported" you can see that isn't
that simple and lots of people might start to get angry.
lu
- --
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+xU3sACgkQ6Ex4woTpDjTNewCfU5cahmNPbgKQJt/2GkbVBh4o
F1gAnjheSaIVRF55g1//9wu5dFe8ga3w
=FlU7
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-09 18:32 ` Greg KH
2012-05-09 18:51 ` Fabio Erculiani
@ 2012-05-17 4:16 ` Steven J Long
1 sibling, 0 replies; 111+ messages in thread
From: Steven J Long @ 2012-05-17 4:16 UTC (permalink / raw
To: gentoo-dev
Greg KH wrote:
> Steven J Long wrote:
>> And that is what we were discussing: possible future coupling between the
>> two, which is much easier to do when the sources are part of the
>> same package.
..
>> OFC you could just assure us that udev will never rely on systemd as a
>> design decision. I can understand that systemd might need close
>> integration with the underlying udev implementation.
>
> Nope, can't make that assurance at all.
>
> Actually, maybe I can make the opposite assurance
Well, thanks for being straightforward about it: clearly you're keeping the
option of udev requiring systemd open, and in fact want to move toward that.
> , let's see what the future brings... :)
>
Yeah, we'll see :) You have udev working nicely, fulfilling a whole load of
use-cases, and now you want to upwardly-couple to er, a service-manager.
Running as pid 1, no less, even though it's not necessary. (I predict that
latter decision will get reversed in a while, just like a /usr partition
went from an anachronism to a grand new design, and xml config formats are
no longer talked about; thankfully binary logs got slammed back out the door
in-kernel at least[1].)
Not build another thing utilising udev and dbus, not even one closely
integrated, but upwardly-couple every Linux system to that new userspace
project. Good luck with that.
steveL.
[1] http://lwn.net/Articles/492134/
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-05-10 23:41 ` Alec Warner
@ 2012-05-17 4:39 ` Steven J Long
0 siblings, 0 replies; 111+ messages in thread
From: Steven J Long @ 2012-05-17 4:39 UTC (permalink / raw
To: gentoo-dev
Alec Warner wrote:
> Fabio Erculiani <lxnay@gentoo.org> wrote:
>> I think expressing my own opinion about Lennart-made software is my
>> right, after all.
>> Firstly, it's almost impossible nowadays to avoid including avahi,
>> systemd and pulseaudio into a desktop distro so, there is no real
>> choice. This issue became a sensible matter for those users who for
>> instance, wanted to have a silly mp3 player working without going
>> through the PA nonsense, really missing the old
>> ALSA-oh-it-was-always-working days.
>
> Er, the source is open, so choice is always there. What I think your
> complaint is the fact that it used to be easy to do those things
> (because upstream supported those options and USE flags exposed them
> to you) and now upstream is not supporting those options and there is
> no easy way to remove the dependencies without doing a bunch of work.
>
I think it's more a matter of process. These changes force major userspace
changes, which since they are not a matter of ABI export, don't really
concern kernel devs (after all, they design for userspace to do crazy stuff,
or their OS is not robust: beyond ABI stability, the contract they fulfil,
in the main they don't really care what happens there.)
However the changes are forced on admins and users, unless we take on a
development effort which means we're no longer just admins or users. And
yeah, people are clearly looking at doing that with mdev, though we'd rather
not have to be forced into that.
>> If you want to bring complexity but you end up not being able to
>> handle it, then you're not a really good engineer, IMHO.
>
> I don't think anyone expects complexity to come bug-free. Cathedral
> and the Bazaar? Release Early and Release Often? I expect the software
> to reach a stable state in a reasonable amount of time given the
> complexity involved.
>
The way to handle complexity is with small, modular components that are
loosely-coupled and cohesive. AKA "Do one thing, and do it well." Like udev
has been doing for quite a while.
>>
>> Having said that, I also wonder where's the lovely modularity the
>> various *nix platforms had. If this is the actual direction of Linux
>> Foundation, Redhat and Canonical, I am worried that Linux would end up
>> being an OSX-wannabe.
>
> The problem as I understand it is that you want other people to write
> software that meets your needs and it turns out that the world doesn't
> always work that way.
>
> You can fork the software you hate (using versions before you hated
> it) or you can write your own software (like mdev + busybox) to
> replace the hated components. Both of those things are actually
> somewhat useful. Complaining about how some random people on the
> internet don't write software that you find palatable is just silly.
>
It's not about that: the point is that massive changes are being pushed
through, and the people who actually have to implement them in the real-
world haven't been consulted. When they are, after their concerns about
administration (you know, their jobs) are dismissed and they're asked for
technical reasons, they draw attention to Unix principles, simply because
they have been proven over decades to be the best basis for software-
engineering.
And please: "random people on the internet"? That's not how I'd describe
upstream udev or kernel maintainers. Or is this your "it's the developer's
playground" philosophy again?
Simply put, there is no space in kernel mailing-lists, nor in upstream udev
et al, to have this discussion. It affects Gentoo users most, because we are
far more likely to run using custom-compiled kernels with base system
modules like motherboard disk-controllers built-in, and to have setup eg
/usr on LVM in accordance with docs, and since we use a rolling-release we
haven't needed to change what wasn't broken.
Nor do many of us think we've heard any benefit to outweigh the
disadvantages. For instance, we've been told several times that a) an
initramfs is the new root, in that we don't need rescue tools on an easy to
mount root anymore, our initramfs will be a souped-up rescue-shell; and b)
that an initramfs is easy to set up and maintain, and should typically only
be a few hundred kilobytes (so it's not going to bloat the boot process.)
Everything I've seen of people's configs in forum posts about setting up
initramfs, and heard of the process, makes me think it's going to be a
custom design per-Gentoo user, and tweaking what's in there is going to be
part of standard setup and ongoing maintenance. Forgive me for assessing
that as a regression in usability.
Ultimately of course, udev maintainers will do what they want. That's fine,
and I'll shut up about the whole thing as my concerns are on the record:
just so long as no-one pretends they've justified the breaches of basic
design principles.
Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
[not found] ` <4bdd949a377d40eb85590870be440551@HUBCAS1.cs.stonybrook.edu>
@ 2012-11-18 7:54 ` Richard Yao
2012-11-18 8:08 ` Greg KH
0 siblings, 1 reply; 111+ messages in thread
From: Richard Yao @ 2012-11-18 7:54 UTC (permalink / raw
To: gentoo-dev@lists.gentoo.org; +Cc: Greg KH
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
On 05/09/2012 06:36 PM, Greg KH wrote:
> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>> I foresee a new udev fork then.
>
> Please feel free to do so, the code has been open since the first day I
> created it.
>
> Remember, forks are good, there's nothing wrong with them, I strongly
> encourage people to do them if they wish to, it benefits everyone
> involved.
>
>> If udev is going to end up like avahi is, this is *highly* probable.
>
> That's an odd transition...
>
>> With "avahi is ..." I actually mean, one single tarball blob depending
>> on the whole world and its solar system and galaxy.
>
> Hyperbole, how nice :(
>
>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
>
> The use of these terms is both rude and totally uncalled for. You
> should be ashamed of yourself.
>
> Seriously, that's unacceptable behavior from anyone.
>
> No one forces you to use any of this software if you do not want to.
> There are lots of other operating systems out there, feel free to switch
> to them if you do not like the way this one is working out, no one is
> stopping you. But for you to disparage someone who has given immense
> bodies of work to the community, and you, for free, is horrible behavior
> and needs to stop right now.
>
> greg k-h
>
Greg, would you clarify what you meant by this?
Your recent comments suggest to me that you did not mean what I thought
you meant.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 7:54 ` [gentoo-dev] " Richard Yao
@ 2012-11-18 8:08 ` Greg KH
2012-11-18 8:10 ` Richard Yao
2012-11-18 8:21 ` Diego Elio Pettenò
0 siblings, 2 replies; 111+ messages in thread
From: Greg KH @ 2012-11-18 8:08 UTC (permalink / raw
To: Richard Yao; +Cc: gentoo-dev@lists.gentoo.org
On Sun, Nov 18, 2012 at 02:54:38AM -0500, Richard Yao wrote:
> On 05/09/2012 06:36 PM, Greg KH wrote:
> > On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
> >> I foresee a new udev fork then.
> >
> > Please feel free to do so, the code has been open since the first day I
> > created it.
> >
> > Remember, forks are good, there's nothing wrong with them, I strongly
> > encourage people to do them if they wish to, it benefits everyone
> > involved.
> >
> >> If udev is going to end up like avahi is, this is *highly* probable.
> >
> > That's an odd transition...
> >
> >> With "avahi is ..." I actually mean, one single tarball blob depending
> >> on the whole world and its solar system and galaxy.
> >
> > Hyperbole, how nice :(
> >
> >> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
> >
> > The use of these terms is both rude and totally uncalled for. You
> > should be ashamed of yourself.
> >
> > Seriously, that's unacceptable behavior from anyone.
> >
> > No one forces you to use any of this software if you do not want to.
> > There are lots of other operating systems out there, feel free to switch
> > to them if you do not like the way this one is working out, no one is
> > stopping you. But for you to disparage someone who has given immense
> > bodies of work to the community, and you, for free, is horrible behavior
> > and needs to stop right now.
> >
> > greg k-h
> >
>
> Greg, would you clarify what you meant by this?
Meant by what part of the above response? Written 6 months ago?
> Your recent comments suggest to me that you did not mean what I thought
> you meant.
What did you think I meant about what?
Again, I have no objection to people forking projects, it's great, and
fun to watch happen. Fork away on your own site, with whom ever you
want to.
But if this fork is now the "official Gentoo fork", owned by the Gentoo
Foundation, and it's the way forward that Gentoo the distro is going to
take with regards to how the boot process works on the system, then I
have something to say about it, as it affects me, a Gentoo developer.
And that is how this thread started, I wanted to know what was the
resolution of the council meeting with the very unclear and vague
meeting minutes. I have yet to get that answer, which is troubling.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 8:08 ` Greg KH
@ 2012-11-18 8:10 ` Richard Yao
2012-11-18 8:19 ` Greg KH
2012-11-18 8:21 ` Diego Elio Pettenò
1 sibling, 1 reply; 111+ messages in thread
From: Richard Yao @ 2012-11-18 8:10 UTC (permalink / raw
To: Greg KH; +Cc: gentoo-dev@lists.gentoo.org
[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]
On 11/18/2012 03:08 AM, Greg KH wrote:
> On Sun, Nov 18, 2012 at 02:54:38AM -0500, Richard Yao wrote:
>> On 05/09/2012 06:36 PM, Greg KH wrote:
>>> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>>>> I foresee a new udev fork then.
>>>
>>> Please feel free to do so, the code has been open since the first day I
>>> created it.
>>>
>>> Remember, forks are good, there's nothing wrong with them, I strongly
>>> encourage people to do them if they wish to, it benefits everyone
>>> involved.
>>>
>>>> If udev is going to end up like avahi is, this is *highly* probable.
>>>
>>> That's an odd transition...
>>>
>>>> With "avahi is ..." I actually mean, one single tarball blob depending
>>>> on the whole world and its solar system and galaxy.
>>>
>>> Hyperbole, how nice :(
>>>
>>>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
>>>
>>> The use of these terms is both rude and totally uncalled for. You
>>> should be ashamed of yourself.
>>>
>>> Seriously, that's unacceptable behavior from anyone.
>>>
>>> No one forces you to use any of this software if you do not want to.
>>> There are lots of other operating systems out there, feel free to switch
>>> to them if you do not like the way this one is working out, no one is
>>> stopping you. But for you to disparage someone who has given immense
>>> bodies of work to the community, and you, for free, is horrible behavior
>>> and needs to stop right now.
>>>
>>> greg k-h
>>>
>>
>> Greg, would you clarify what you meant by this?
>
> Meant by what part of the above response? Written 6 months ago?
>
>> Your recent comments suggest to me that you did not mean what I thought
>> you meant.
>
> What did you think I meant about what?
>
> Again, I have no objection to people forking projects, it's great, and
> fun to watch happen. Fork away on your own site, with whom ever you
> want to.
>
> But if this fork is now the "official Gentoo fork", owned by the Gentoo
> Foundation, and it's the way forward that Gentoo the distro is going to
> take with regards to how the boot process works on the system, then I
> have something to say about it, as it affects me, a Gentoo developer.
>
> And that is how this thread started, I wanted to know what was the
> resolution of the council meeting with the very unclear and vague
> meeting minutes. I have yet to get that answer, which is troubling.
>
> thanks,
>
> greg k-h
You are the one claiming that this is our official fork. None of us are.
This will be an official Gentoo project when we make the announcement in
the next few days. That makes it one project of many. GLEP 0039 clearly
states how this works. If you are unhappy with GLEP 0039, then you
should discuss that with the council.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 8:10 ` Richard Yao
@ 2012-11-18 8:19 ` Greg KH
2012-11-18 8:19 ` Richard Yao
2012-11-18 8:27 ` Greg KH
0 siblings, 2 replies; 111+ messages in thread
From: Greg KH @ 2012-11-18 8:19 UTC (permalink / raw
To: Richard Yao; +Cc: gentoo-dev@lists.gentoo.org
On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote:
> You are the one claiming that this is our official fork. None of us are.
It's on the Gentoo github site, and it has the Gentoo Foundation
copyright all over all of the files in one of the branches, reviewed by
you.
I think I would be pretty foolish if I somehow thought it was _not_ an
official fork :)
> This will be an official Gentoo project when we make the announcement in
> the next few days. That makes it one project of many. GLEP 0039 clearly
> states how this works. If you are unhappy with GLEP 0039, then you
> should discuss that with the council.
I fail to see how 0039 has to do with this, please explain. I also
don't see the copyright issue here, nor do I see where the decision of
the council was made.
Again, that's my original question, "What is the decision of the council
regarding this issue"?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 8:19 ` Greg KH
@ 2012-11-18 8:19 ` Richard Yao
2012-11-18 8:27 ` Greg KH
1 sibling, 0 replies; 111+ messages in thread
From: Richard Yao @ 2012-11-18 8:19 UTC (permalink / raw
To: Greg KH; +Cc: gentoo-dev@lists.gentoo.org
[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]
On 11/18/2012 03:19 AM, Greg KH wrote:
> On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote:
>> You are the one claiming that this is our official fork. None of us are.
>
> It's on the Gentoo github site, and it has the Gentoo Foundation
> copyright all over all of the files in one of the branches, reviewed by
> you.
>
> I think I would be pretty foolish if I somehow thought it was _not_ an
> official fork :)
>
>> This will be an official Gentoo project when we make the announcement in
>> the next few days. That makes it one project of many. GLEP 0039 clearly
>> states how this works. If you are unhappy with GLEP 0039, then you
>> should discuss that with the council.
>
> I fail to see how 0039 has to do with this, please explain. I also
> don't see the copyright issue here, nor do I see where the decision of
> the council was made.
>
> Again, that's my original question, "What is the decision of the council
> regarding this issue"?
>
> thanks,
>
> greg k-h
I am sick of the harassment that I have received from you and a few
others both in public and in private. The public branch has been
deleted. Come back after we have done our first release. Otherwise,
leave us alone. That is all that I have to say.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 8:08 ` Greg KH
2012-11-18 8:10 ` Richard Yao
@ 2012-11-18 8:21 ` Diego Elio Pettenò
2012-11-18 8:49 ` Samuli Suominen
2012-11-18 11:11 ` Vadim A. Misbakh-Soloviov
1 sibling, 2 replies; 111+ messages in thread
From: Diego Elio Pettenò @ 2012-11-18 8:21 UTC (permalink / raw
To: gentoo-dev
On 18/11/2012 00:08, Greg KH wrote:
> But if this fork is now the "official Gentoo fork", owned by the Gentoo
> Foundation, and it's the way forward that Gentoo the distro is going to
> take with regards to how the boot process works on the system, then I
> have something to say about it, as it affects me, a Gentoo developer.
Please note that I would be the first one, from a QA point of view, to
raise a huge question mark if somebody is planning to make this the
default anytime soon.
You want to keep it around as an option? Sure, feel free.
Moving as default? Over my dead public key.
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 8:19 ` Greg KH
2012-11-18 8:19 ` Richard Yao
@ 2012-11-18 8:27 ` Greg KH
2012-11-18 8:38 ` Pacho Ramos
1 sibling, 1 reply; 111+ messages in thread
From: Greg KH @ 2012-11-18 8:27 UTC (permalink / raw
To: gentoo-dev; +Cc: Richard Yao
On Sun, Nov 18, 2012 at 12:19:21AM -0800, Greg KH wrote:
> On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote:
> > You are the one claiming that this is our official fork. None of us are.
>
> It's on the Gentoo github site, and it has the Gentoo Foundation
> copyright all over all of the files in one of the branches, reviewed by
> you.
>
> I think I would be pretty foolish if I somehow thought it was _not_ an
> official fork :)
Oh, and the README file says it is a Gentoo project:
This is a Gentoo sponsored project and testing is currently
being done with openrc. However, we aim to be distro neutral
and welcome contribution from others using a variety of system
initializations. We also aim towards POSIX compliance.
So why would I think otherwise?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 8:27 ` Greg KH
@ 2012-11-18 8:38 ` Pacho Ramos
0 siblings, 0 replies; 111+ messages in thread
From: Pacho Ramos @ 2012-11-18 8:38 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]
El dom, 18-11-2012 a las 00:27 -0800, Greg KH escribió:
> On Sun, Nov 18, 2012 at 12:19:21AM -0800, Greg KH wrote:
> > On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote:
> > > You are the one claiming that this is our official fork. None of us are.
> >
> > It's on the Gentoo github site, and it has the Gentoo Foundation
> > copyright all over all of the files in one of the branches, reviewed by
> > you.
> >
> > I think I would be pretty foolish if I somehow thought it was _not_ an
> > official fork :)
>
> Oh, and the README file says it is a Gentoo project:
> This is a Gentoo sponsored project and testing is currently
> being done with openrc. However, we aim to be distro neutral
> and welcome contribution from others using a variety of system
> initializations. We also aim towards POSIX compliance.
>
> So why would I think otherwise?
>
> thanks,
>
> greg k-h
>
>
Looks like we think different about what a "Gentoo project" means, lets
read:
http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html
That would explain why both, eudev and systemd "Gentoo projects" can
coexist:
http://www.gentoo.org/proj/en/base/systemd/index.xml
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 8:21 ` Diego Elio Pettenò
@ 2012-11-18 8:49 ` Samuli Suominen
2012-11-18 11:11 ` Vadim A. Misbakh-Soloviov
1 sibling, 0 replies; 111+ messages in thread
From: Samuli Suominen @ 2012-11-18 8:49 UTC (permalink / raw
To: gentoo-dev
On 18/11/12 10:21, Diego Elio Pettenò wrote:
> On 18/11/2012 00:08, Greg KH wrote:
>> But if this fork is now the "official Gentoo fork", owned by the Gentoo
>> Foundation, and it's the way forward that Gentoo the distro is going to
>> take with regards to how the boot process works on the system, then I
>> have something to say about it, as it affects me, a Gentoo developer.
>
> Please note that I would be the first one, from a QA point of view, to
> raise a huge question mark if somebody is planning to make this the
> default anytime soon.
>
> You want to keep it around as an option? Sure, feel free.
>
> Moving as default? Over my dead public key.
>
Amen.
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 8:21 ` Diego Elio Pettenò
2012-11-18 8:49 ` Samuli Suominen
@ 2012-11-18 11:11 ` Vadim A. Misbakh-Soloviov
2012-11-18 12:26 ` Rich Freeman
2012-11-18 15:04 ` [gentoo-dev] " Diego Elio Pettenò
1 sibling, 2 replies; 111+ messages in thread
From: Vadim A. Misbakh-Soloviov @ 2012-11-18 11:11 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
By the way, Diego, what is you current point of view on Gentoo default
init system?
i.e., what do you personally prefer to see as default init here: SystemD
or OpenRC?
[Just asking because all you angry answers to some devs make me think
that you're on SysD side, when tons of Gentoo users and Gentoo devs are
on "non-SysD-related udev" side.]
And, if anyone is interested in my opinion: I *HATE* when somebody (will
it be distro maintainers or RedHat corporation) forcing me their opinion
on _what_ should I use and _how_ should I use this. Thats why I hate
Ubuntu, Debian, CentOS, RHEL, SuSE and so on.
Thats why I'm using Gentoo and Gentoo-derivatives (Sabayon, for
example) for almost 10 years.
Thats why I am an evangelist of Gentoo and it's derivatives.
More of that, thats why Daniel Robbins created Gentoo itself.
So, I really hope, that Gentoo will not obey RedHat's will and will not
force SystemD as default init system, and not drop pretty OpenRC to
trash. And I hope, that ryao's eudev will be most used (if not default)
variant of udev, since I'm sad with last vanilla udev functionality
"downgrades".
--
Best,
mva
18.11.2012 15:21, Diego Elio Pettenò пишет:
> On 18/11/2012 00:08, Greg KH wrote:
>> But if this fork is now the "official Gentoo fork", owned by the Gentoo
>> Foundation, and it's the way forward that Gentoo the distro is going to
>> take with regards to how the boot process works on the system, then I
>> have something to say about it, as it affects me, a Gentoo developer.
>
> Please note that I would be the first one, from a QA point of view, to
> raise a huge question mark if somebody is planning to make this the
> default anytime soon.
>
> You want to keep it around as an option? Sure, feel free.
>
> Moving as default? Over my dead public key.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 11:11 ` Vadim A. Misbakh-Soloviov
@ 2012-11-18 12:26 ` Rich Freeman
2012-11-18 16:49 ` [gentoo-dev] " Duncan
2012-11-18 15:04 ` [gentoo-dev] " Diego Elio Pettenò
1 sibling, 1 reply; 111+ messages in thread
From: Rich Freeman @ 2012-11-18 12:26 UTC (permalink / raw
To: gentoo-dev
On Sun, Nov 18, 2012 at 6:11 AM, Vadim A. Misbakh-Soloviov <mva@mva.name> wrote:
> So, I really hope, that Gentoo will not obey RedHat's will and will not
> force SystemD as default init system, and not drop pretty OpenRC to
> trash. And I hope, that ryao's eudev will be most used (if not default)
> variant of udev, since I'm sad with last vanilla udev functionality
> "downgrades".
I'm sure all of the options will be offered as options for as long as
people care to take care of them. With the number of anti-systemd
posts on -dev I don't see openrc going away anytime soon.
I'm sure the default will stay as it is unless a substantial majority
want it otherwise - we can't go flipping that every time the latest
whatever comes along.
And frankly, I could care less what it is since I can change it. If I
wanted to be rigidly bound by defaults there are a lot of distros
easier to maintain than Gentoo. iOS comes to mind. :)
I run OpenRC on my main box, and systemd on a VM hosted within it. I
wouldn't be surprised if I move to systemd some day as my experience
with it has been a good one, but I'll use the tools I think are best
for the problem at hand, and not what somebody else chooses for me,
and I'll be the last to force a choice on anybody else. That said,
Gentoo can only offer the options that devs step up and maintain, so
if you care greatly about something start writing patches.
That is my biggest concern over a lot of this mess - and Greg KH did a
good job putting it into words in the six-month old thread that was
just resurrected. Lennart et al only have the power you give to them
- anybody can fork at any time or keep an old project going. If you
don't like Gnome 3 then start writing code for Gnome 2. This is all
FREE software, and it only exists when people take the time to write
it. If nobody bothers to maintain the alternatives, then I guess
collectively we're going to be stuck with whatever people take the
time to write.
So, feel free to offer advice/comments/etc. However, let's keep the
tone civil. Unless you're their employer, the guys writing the
software you don't like owe you precisely nothing.
Rich
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 11:11 ` Vadim A. Misbakh-Soloviov
2012-11-18 12:26 ` Rich Freeman
@ 2012-11-18 15:04 ` Diego Elio Pettenò
2012-11-18 15:16 ` Samuli Suominen
2012-11-18 15:43 ` [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012] Vadim A. Misbakh-Soloviov
1 sibling, 2 replies; 111+ messages in thread
From: Diego Elio Pettenò @ 2012-11-18 15:04 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
On 18/11/2012 03:11, Vadim A. Misbakh-Soloviov wrote:
>
> [Just asking because all you angry answers to some devs make me think
> that you're on SysD side, when tons of Gentoo users and Gentoo devs are
> on "non-SysD-related udev" side.]
The fact you're asking means you really haven't been following anything
I've been doing lately. As many other developers can easily attest, I
don't use systemd and I'm not planning to use it anytime soon.
So your whole rant picking up on my post is completely misdirected.
And let this be a reminder that you can still disagree with the "systemd
everywhere, and only" crowd while still not becoming laughing stock.
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:04 ` [gentoo-dev] " Diego Elio Pettenò
@ 2012-11-18 15:16 ` Samuli Suominen
2012-11-18 15:31 ` Diego Elio Pettenò
` (3 more replies)
2012-11-18 15:43 ` [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012] Vadim A. Misbakh-Soloviov
1 sibling, 4 replies; 111+ messages in thread
From: Samuli Suominen @ 2012-11-18 15:16 UTC (permalink / raw
To: gentoo-dev
On 18/11/12 17:04, Diego Elio Pettenò wrote:
> On 18/11/2012 03:11, Vadim A. Misbakh-Soloviov wrote:
>>
>> [Just asking because all you angry answers to some devs make me think
>> that you're on SysD side, when tons of Gentoo users and Gentoo devs are
>> on "non-SysD-related udev" side.]
>
> The fact you're asking means you really haven't been following anything
> I've been doing lately. As many other developers can easily attest, I
> don't use systemd and I'm not planning to use it anytime soon.
>
> So your whole rant picking up on my post is completely misdirected.
Same here. I haven't even tried it and got no plans to.
I'm still happy enough with building udev out from systemd tree and
letting sep. /usr consept from 90s to finally die in favour of
simplifying the system.
The BIOSes have been upgraded last century to support booting from
larger partitions, the need has long past.
Nobody has ever provided a valid reason for using sep. /usr in the ML
either.
- Samuli
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:16 ` Samuli Suominen
@ 2012-11-18 15:31 ` Diego Elio Pettenò
2012-11-18 15:32 ` Fabian Groffen
` (2 subsequent siblings)
3 siblings, 0 replies; 111+ messages in thread
From: Diego Elio Pettenò @ 2012-11-18 15:31 UTC (permalink / raw
To: gentoo-dev
On 18/11/2012 07:16, Samuli Suominen wrote:
>
>
> I'm still happy enough with building udev out from systemd tree and
> letting sep. /usr consept from 90s to finally die in favour of
> simplifying the system.
> The BIOSes have been upgraded last century to support booting from
> larger partitions, the need has long past.
> Nobody has ever provided a valid reason for using sep. /usr in the ML
> either.
Ibidem.
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:16 ` Samuli Suominen
2012-11-18 15:31 ` Diego Elio Pettenò
@ 2012-11-18 15:32 ` Fabian Groffen
2012-11-18 15:34 ` Vadim A. Misbakh-Soloviov
2012-11-19 13:07 ` [gentoo-dev] Re: Tightly-coupled core distro Steven J. Long
3 siblings, 0 replies; 111+ messages in thread
From: Fabian Groffen @ 2012-11-18 15:32 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 355 bytes --]
On 18-11-2012 17:16:18 +0200, Samuli Suominen wrote:
> Nobody has ever provided a valid reason for using sep. /usr in the ML
> either.
No need for a reason.
It is a fact that it is in use *right now*.
(Existing systems/installs that are not to be phased out anywhere near
soon.)
Fabian
--
Fabian Groffen
Gentoo on a different level
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:16 ` Samuli Suominen
2012-11-18 15:31 ` Diego Elio Pettenò
2012-11-18 15:32 ` Fabian Groffen
@ 2012-11-18 15:34 ` Vadim A. Misbakh-Soloviov
2012-11-18 15:42 ` Diego Elio Pettenò
2012-11-18 15:50 ` Luca Barbato
2012-11-19 13:07 ` [gentoo-dev] Re: Tightly-coupled core distro Steven J. Long
3 siblings, 2 replies; 111+ messages in thread
From: Vadim A. Misbakh-Soloviov @ 2012-11-18 15:34 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]
To be honest, in my opinion, «killing of separate /usr» can reasonable
be continued by moving all it's content to / (/usr/bin -> /bin, /usr/lib
-> lib, and so on) in despite of all objections, as it was invented just
because of disk space exhaustion.
18.11.2012 22:16, Samuli Suominen пишет:
> On 18/11/12 17:04, Diego Elio Pettenò wrote:
>> On 18/11/2012 03:11, Vadim A. Misbakh-Soloviov wrote:
>>>
>>> [Just asking because all you angry answers to some devs make me think
>>> that you're on SysD side, when tons of Gentoo users and Gentoo devs are
>>> on "non-SysD-related udev" side.]
>>
>> The fact you're asking means you really haven't been following anything
>> I've been doing lately. As many other developers can easily attest, I
>> don't use systemd and I'm not planning to use it anytime soon.
>>
>> So your whole rant picking up on my post is completely misdirected.
>
> Same here. I haven't even tried it and got no plans to.
>
> I'm still happy enough with building udev out from systemd tree and
> letting sep. /usr consept from 90s to finally die in favour of
> simplifying the system.
> The BIOSes have been upgraded last century to support booting from
> larger partitions, the need has long past.
> Nobody has ever provided a valid reason for using sep. /usr in the ML
> either.
>
> - Samuli
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:34 ` Vadim A. Misbakh-Soloviov
@ 2012-11-18 15:42 ` Diego Elio Pettenò
2012-11-18 15:51 ` Fabian Groffen
2012-11-18 15:50 ` Luca Barbato
1 sibling, 1 reply; 111+ messages in thread
From: Diego Elio Pettenò @ 2012-11-18 15:42 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
On 18/11/2012 07:34, Vadim A. Misbakh-Soloviov wrote:
> To be honest, in my opinion, «killing of separate /usr» can reasonable
> be continued by moving all it's content to / (/usr/bin -> /bin, /usr/lib
> -> lib, and so on) in despite of all objections, as it was invented just
> because of disk space exhaustion.
Well, the objection to that was what actually "caused" this udev fork, so...
Also, I doubt anybody would argue that it's not commutative (move to
/usr, move to /) — it's just pragmatic, most stuff uses /usr anyway as
base, so the move / -> /usr is infinitely less painful than /usr -> /.
To me, I don't care. I haven't even used /boot in years.
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:04 ` [gentoo-dev] " Diego Elio Pettenò
2012-11-18 15:16 ` Samuli Suominen
@ 2012-11-18 15:43 ` Vadim A. Misbakh-Soloviov
2012-11-18 15:47 ` Diego Elio Pettenò
1 sibling, 1 reply; 111+ messages in thread
From: Vadim A. Misbakh-Soloviov @ 2012-11-18 15:43 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
> The fact you're asking means you really haven't been following anything
> I've been doing lately.
Nope ;) I knew that, but as far as I read some of your emails, it was
thoughts that you protect udev+sysD integration and followed udev's
functionality downgrade.
> So your whole rant picking up on my post is completely misdirected.
Sorry, if I write it in that manner, that last part looks like adressed
to you. I tried to write it mostly for GregKH and people, that protect
SystemD-way distro-development path.
> And let this be a reminder that you can still disagree with the "systemd
> everywhere, and only" crowd while still not becoming laughing stock.
And, by the way, I doubt, that people "laugh" about eudev (previously
named udev-ng) creation. Mostly they just can't understand why gentoo
devs created third udev's fork, where it was already done (and
maintained) fork for LFS (somewhere on bitbucket)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:43 ` [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012] Vadim A. Misbakh-Soloviov
@ 2012-11-18 15:47 ` Diego Elio Pettenò
2012-11-18 15:54 ` Fabian Groffen
` (2 more replies)
0 siblings, 3 replies; 111+ messages in thread
From: Diego Elio Pettenò @ 2012-11-18 15:47 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 572 bytes --]
On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote:
> And, by the way, I doubt, that people "laugh" about eudev (previously
> named udev-ng) creation. Mostly they just can't understand why gentoo
> devs created third udev's fork, where it was already done (and
> maintained) fork for LFS (somewhere on bitbucket)
People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and
IRC as well.
But yes, many more can't understand that... and neither do I.
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:34 ` Vadim A. Misbakh-Soloviov
2012-11-18 15:42 ` Diego Elio Pettenò
@ 2012-11-18 15:50 ` Luca Barbato
1 sibling, 0 replies; 111+ messages in thread
From: Luca Barbato @ 2012-11-18 15:50 UTC (permalink / raw
To: gentoo-dev
On 11/18/2012 04:34 PM, Vadim A. Misbakh-Soloviov wrote:
> To be honest, in my opinion, «killing of separate /usr» can reasonable
> be continued by moving all it's content to / (/usr/bin -> /bin, /usr/lib
> -> lib, and so on) in despite of all objections, as it was invented just
> because of disk space exhaustion.
And since we have lots of wonderful file systems, a neat and interesting
device mapper and a plethora of fun way to shot ourselves in the foot
not only you have a separate /usr but even fun separate /usr/bin from
/usr/share and other strange layout that some people prepared to solve
some of their problems.
The radical solution is to have a rich early boot able to do this kind
of setup, for the transition you might want to not have init and udev
non-workable because somebody decided that is useful using glib or some
other library residing in /usr/
lu
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:42 ` Diego Elio Pettenò
@ 2012-11-18 15:51 ` Fabian Groffen
2012-11-19 8:20 ` Vadim A. Misbakh-Soloviov
0 siblings, 1 reply; 111+ messages in thread
From: Fabian Groffen @ 2012-11-18 15:51 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
On 18-11-2012 07:42:40 -0800, Diego Elio Pettenò wrote:
> Also, I doubt anybody would argue that it's not commutative (move to
> /usr, move to /) — it's just pragmatic, most stuff uses /usr anyway as
> base, so the move / -> /usr is infinitely less painful than /usr -> /.
You end up with a symlink (e.g. bin -> ./usr/bin) from one place to the
other regardless, so it doesn't matter much.
--
Fabian Groffen
Gentoo on a different level
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:47 ` Diego Elio Pettenò
@ 2012-11-18 15:54 ` Fabian Groffen
2012-11-18 16:00 ` Diego Elio Pettenò
2012-11-18 15:56 ` Luca Barbato
2012-11-18 17:19 ` [gentoo-dev] " Duncan
2 siblings, 1 reply; 111+ messages in thread
From: Fabian Groffen @ 2012-11-18 15:54 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On 18-11-2012 07:47:22 -0800, Diego Elio Pettenò wrote:
> On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote:
> > And, by the way, I doubt, that people "laugh" about eudev (previously
> > named udev-ng) creation. Mostly they just can't understand why gentoo
> > devs created third udev's fork, where it was already done (and
> > maintained) fork for LFS (somewhere on bitbucket)
>
> People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and
> IRC as well.
It's your choice to participate on those social platforms. Please don't
make it our problem. It doesn't add anything useful to this discussion.
Fabian
--
Fabian Groffen
Gentoo on a different level
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:47 ` Diego Elio Pettenò
2012-11-18 15:54 ` Fabian Groffen
@ 2012-11-18 15:56 ` Luca Barbato
2012-11-18 17:19 ` [gentoo-dev] " Duncan
2 siblings, 0 replies; 111+ messages in thread
From: Luca Barbato @ 2012-11-18 15:56 UTC (permalink / raw
To: gentoo-dev
On 11/18/2012 04:47 PM, Diego Elio Pettenò wrote:
> But yes, many more can't understand that... and neither do I.
Then would be nice if everybody shuts up, let people play with their
toys and if something useful happens evaluate the result.
According to the people that asked me to help the whole thing would had
been an experiment to see if would be possible to have a smaller and
cleaner udev.
I liked the idea since I like alternatives and I consider many choices
from upstream a tad narrow minded (beside the entertaining posts from
Linus about their bug management).
Nobody wanted hype there, just more people willing to chip in some time
and effort to get there.
lu
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:54 ` Fabian Groffen
@ 2012-11-18 16:00 ` Diego Elio Pettenò
2012-11-18 16:14 ` Fabio Erculiani
0 siblings, 1 reply; 111+ messages in thread
From: Diego Elio Pettenò @ 2012-11-18 16:00 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 917 bytes --]
On 18/11/2012 07:54, Fabian Groffen wrote:
> It's your choice to participate on those social platforms. Please don't
> make it our problem. It doesn't add anything useful to this discussion.
It adds. Because, while I don't know about you, I rely on Gentoo on my
job. And many others do, too.
And making Gentoo the laughing stock (_again_, I'd add) is something
that is detrimental to all of us there, as it makes it harder to let it
be seen for what it is (a very real, quit reliable distribution) rather
than a juvenile effort to be different from the rest.
How long did it take us to get rid of the "Gentoo is rice" fame? Do we
want to go back to that? _I_ don't think so.
So yes, the "social platforms" matter and are our problem. And it appals
me that a member of the council can't see that.
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 16:00 ` Diego Elio Pettenò
@ 2012-11-18 16:14 ` Fabio Erculiani
0 siblings, 0 replies; 111+ messages in thread
From: Fabio Erculiani @ 2012-11-18 16:14 UTC (permalink / raw
To: gentoo-dev
It depends on who is actually laughing I'd say.
just my 0.01c.
--
Fabio Erculiani
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 12:26 ` Rich Freeman
@ 2012-11-18 16:49 ` Duncan
0 siblings, 0 replies; 111+ messages in thread
From: Duncan @ 2012-11-18 16:49 UTC (permalink / raw
To: gentoo-dev
Rich Freeman posted on Sun, 18 Nov 2012 07:26:17 -0500 as excerpted:
> I'm sure all of the options will be offered as options for as long as
> people care to take care of them. With the number of anti-systemd posts
> on -dev I don't see openrc going away anytime soon.
>
> I'm sure the default will stay as it is unless a substantial majority
> want it otherwise - we can't go flipping that every time the latest
> whatever comes along.
[For close followers of the discussion, this is a repeat. But it's worth
repeating in the hope that the message gets out to gentoo users who don't
follow so closely.]
Based on previous posts from other gentoo users, this point seems to have
been lost on some, but it's absolutely true. As I've pointed out before
as well, even if by some miracle all of gentoo turned on a dime and
became a virulently pro-systemd distro today, in practice it'd take time
for that to work into the implementation. We're looking at probably a
year minimum, more practically closer to two, before end-users could
really be "forced" over, and that's if somehow the policy changed on a
dime, today, which isn't going to happen. So even if gentoo ultimately
heads that direction, and I think the default _may_ _eventually_ be
systemd but with *SERIOUS* stress on BOTH _MAY_ and _EVENTUALLY_, in
reality we're looking at 3-5 years.
And in the free software world, a _LOT_ happens in 3-5 years! So much so
that five years really is at the horizon in any case -- there will be
enough currently unforeseen changes between now and then that it's really
hard to predict anything out that far anyway, and MOST people attempting
to do so in anything but trivial ways will get MAJOR parts of their
prediction wrong, simply because events will overtake them.
> And frankly, I could care less what it is since I can change it. If I
> wanted to be rigidly bound by defaults there are a lot of distros easier
> to maintain than Gentoo. iOS comes to mind. :)
That's a point that should be near and dear to any serious gentooer's
heart! =:^)
> I run OpenRC on my main box, and systemd on a VM hosted within it. I
> wouldn't be surprised if I move to systemd some day as my experience
> with it has been a good one, but I'll use the tools I think are best for
> the problem at hand, and not what somebody else chooses for me, and I'll
> be the last to force a choice on anybody else.
With the previous caveats about trying to predict anything in the FLOSS
world too far out, in 2-3 years, I expect I'll be on systemd myself. But
there's no rush, and I intend to wait until it stabilizes somewhat,
first. At present it's simply evolving too fast for my tastes, for
something so system-basic. I enjoy running alphas and betas as much as
the next guy and it's a rare time indeed that I don't have /something/
not-absolutely stable running on my systems, but that doesn't mean I
want /all/ of my system unstable and shifting out from under me, and
system init is an area where I'm just not ready to make a change as big
as systemd, when it's still actively growing and changing at the rate it
seems to be doing so today.
That said, I _do_ run openrc-9999, mainly because I found the changes of
~arch openrc too coarse-grained and hard to troubleshoot when things go
wrong. By running the live-git version and examining git-whatchanged
every time I update, often looking at the diffs for individual commits, I
get the incremental changes as they come in, and can much faster pinpoint
where a particular problem is when I see it, making the necessary changes
locally and of course bug-filing upstream as I need to, to get it fixed.
But running a live-git version of something I'm already on, in ordered to
more closely follow individual commits and pinpoint and resolve bugs
faster, is quite different from deciding I'm going to switch to something
with as much churn as systemd seems to still have, engulfing and
extinguishing entire projects like some ravenous black hole or gray goo.
Yes, I expect at some point I'll be assimilated myself, but there's no
reason that point needs to be now, and the future where I expect it to
happen remains to be written, with a good chance the plot line will
change significantly between now and then, such that I may never be
assimilated after all. For all I know, the whole worldview will change
between now and then, and other events might well overtake this gray goo
that now seems to be engulfing everything that it touches, such that it
never does in fact engulf me and my systems.
> That said, Gentoo can
> only offer the options that devs step up and maintain, so if you care
> greatly about something start writing patches.
This too is a point that's often lost on people. Take kde as an
example. Yes, kde3 was relegated to the kde-sunset overlay, where it's
being maintained in some state by users (see the gentoo-desktop list for
the discussion on that, if interested). But that was simply because no
current gentoo devs were interested in maintaining it in-tree. All the
gentoo/kde folks were on kde4. If there had been active devs interested
in keeping a working kde3 in-tree, it would have stayed in-tree. Only
when the active gentoo dev interest fell below a sustainable level was it
removed, and even then, it's still in kde-sunset, because there's
sustainable interest at /that/ level.
The same of course applies to trinity, the still active fork from kde3.
I think it'd be great to have it in the gentoo tree again. But it's not
going to happen unless/until there's enough active gentoo devs interested
in making it happen to have it as a project.
And the same applies to systemd/udev. The choices available to gentoo
users are a direct reflection of the interest of gentoo devs. As it
happens, there's a couple gentoo devs with the interest and motivation to
have the systemd OPTION in gentoo, but that's exactly where it stands
ATM, a non-default OPTION. And that's exactly where it's likely to
remain for at least a few years, because the primary gentoo dev interest
still seems to be focused on openrc and a udev-alike that remains
sufficiently unentangled from systemd that it's still buildable (to some
degree) and runnable (to a much larger degree) on its own.
The only way that's going to change is if the critical level of interest
amongst gentoo devs changes. Thus, the way to either keep a gentoo
systemd default from happening, or increase the speed at which it
happens, and to maintain choice regardless of the default depending on
your own interest, is to do your part to ensure the critical level of
gentoo interest in your preferred outcome remains strong.
If current wider-Linux-and-FLOSS-universe trends continue, then at some
point, probably most gentoo devs will be interested in systemd, as it's
what they're familiar with from their previous and continuing outside-of-
gentoo experience. However, as I pointed out above, that's not a
particularly safe prediction to make, because gentoo as it is today is
rather far from that, and by the time it could reasonably get to that
point thru normal gentoo dev attrition and recruitment, the whole Linux/
FLOSS worldview may well have changed, and systemd/udev may well be as
much yesterday's news as the old kernel's even/odd stable/dev kernel
cycle, or the xfree86/xorg split before that, or the gcc/egcs split
before that, or...
> That is my biggest concern over a lot of this mess - and Greg KH did a
> good job putting it into words in the six-month old thread that was just
> resurrected. Lennart et al only have the power you give to them -
> anybody can fork at any time or keep an old project going. If you don't
> like Gnome 3 then start writing code for Gnome 2. This is all FREE
> software, and it only exists when people take the time to write it. If
> nobody bothers to maintain the alternatives, then I guess collectively
> we're going to be stuck with whatever people take the time to write.
This is simply reinforcing and underlining the above, only now we're
looking at the upstream level, not the gentoo/distro level.
> So, feel free to offer advice/comments/etc. However, let's keep the
> tone civil. Unless you're their employer, the guys writing the software
> you don't like owe you precisely nothing.
++ on keeping it civil! =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:47 ` Diego Elio Pettenò
2012-11-18 15:54 ` Fabian Groffen
2012-11-18 15:56 ` Luca Barbato
@ 2012-11-18 17:19 ` Duncan
2012-11-18 18:15 ` Stelian Ionescu
2 siblings, 1 reply; 111+ messages in thread
From: Duncan @ 2012-11-18 17:19 UTC (permalink / raw
To: gentoo-dev
Diego Elio Pettenò posted on Sun, 18 Nov 2012 07:47:22 -0800 as excerpted:
> On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote:
>> And, by the way, I doubt, that people "laugh" about eudev (previously
>> named udev-ng) creation. Mostly they just can't understand why gentoo
>> devs created third udev's fork, where it was already done (and
>> maintained) fork for LFS (somewhere on bitbucket)
>
> People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and
> IRC as well.
There's worse things than being laughed it. In fact, what's the oft-used-
in-MS/Linux-context quote (Gandi if I'm not mistaken), something along
the lines of...
First they ignore you, then they laugh at you, then they fight you, then
you win!
If they're laughing, they're beyond the ignore stage. And we see
evidence of the fight stage now too. If the idea behind that quote is
correct...
But regardless, there's quite some coding to do before we see.
Meanwhile, it may fizzle out, or other events may overtake. Anyway you
look at it tho, things could be interesting.
But there's still worse things than being laughed at. Gentoo continued
in spite of the ricer rep it once had, and this project seems to be being
blown WAY out of proportion in all KINDS of ways, but gentoo will still
continue, regardless.
(All that said, the copyright/legal thing is a bit concerning, but it
already seems to be on its way to being worked out, best I can tell, so
it too seems to have been blown way out of proportion, tho it may well
have been felt that was necessary in ordered to stress the gravity of the
situation. As many find out too late, legal isn't a laughing matter, but
regardless, that angle /does/ appear to be being addressed. The
others... let them laugh.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 17:19 ` [gentoo-dev] " Duncan
@ 2012-11-18 18:15 ` Stelian Ionescu
0 siblings, 0 replies; 111+ messages in thread
From: Stelian Ionescu @ 2012-11-18 18:15 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]
On Sun, 2012-11-18 at 17:19 +0000, Duncan wrote:
> Diego Elio Pettenò posted on Sun, 18 Nov 2012 07:47:22 -0800 as excerpted:
>
> > On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote:
> >> And, by the way, I doubt, that people "laugh" about eudev (previously
> >> named udev-ng) creation. Mostly they just can't understand why gentoo
> >> devs created third udev's fork, where it was already done (and
> >> maintained) fork for LFS (somewhere on bitbucket)
> >
> > People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and
> > IRC as well.
>
> There's worse things than being laughed it. In fact, what's the oft-used-
> in-MS/Linux-context quote (Gandi if I'm not mistaken), something along
> the lines of...
>
> First they ignore you, then they laugh at you, then they fight you, then
> you win!
>
> If they're laughing, they're beyond the ignore stage. And we see
> evidence of the fight stage now too. If the idea behind that quote is
> correct...
People keep repeating that quote implying that whenever somebody laughs
at an idea it's because the idea is worth something, but that's
illogical and in fact false: just because B(worthy idea) was preceded by
A(laughter) doesn't mean that whenever there's A(laughter) then B(worthy
idea) ensues
http://xkcd.com/386/
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-18 15:51 ` Fabian Groffen
@ 2012-11-19 8:20 ` Vadim A. Misbakh-Soloviov
2012-11-19 12:14 ` Rich Freeman
2012-11-19 13:08 ` Fabian Groffen
0 siblings, 2 replies; 111+ messages in thread
From: Vadim A. Misbakh-Soloviov @ 2012-11-19 8:20 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 272 bytes --]
18.11.2012 22:51, Fabian Groffen пишет:
> You end up with a symlink (e.g. bin -> ./usr/bin) from one place to the
> other regardless, so it doesn't matter much.
So, why not to make /usr/bin -> ../bin (or, maybe even /usr/bin -> /bin
(notice the «/»)) ? :D
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-19 8:20 ` Vadim A. Misbakh-Soloviov
@ 2012-11-19 12:14 ` Rich Freeman
2012-11-19 13:08 ` Fabian Groffen
1 sibling, 0 replies; 111+ messages in thread
From: Rich Freeman @ 2012-11-19 12:14 UTC (permalink / raw
To: gentoo-dev
On Mon, Nov 19, 2012 at 3:20 AM, Vadim A. Misbakh-Soloviov <mva@mva.name> wrote:
> 18.11.2012 22:51, Fabian Groffen пишет:
>> You end up with a symlink (e.g. bin -> ./usr/bin) from one place to the
>> other regardless, so it doesn't matter much.
>
> So, why not to make /usr/bin -> ../bin (or, maybe even /usr/bin -> /bin
> (notice the «/»)) ? :D
So, given the choices of:
1. Re-establishing FHS standards so that I can boot with / only.
2. Consolidating everything under /usr so that just about all
OS-managed files are in a single place.
3. Stuffing everything in /usr into my root partition.
I'd say that #3 is the worst of all possible worlds. At least there
is some kind of expected benefit from the /usr move. Sure, you COULD
shove everything into root, but I can't think of anybody in this
debate who would consider that a useful solution.
Go read the Fedora reasons-for-the-/usr-move page. Whether you think
it is worth it or not is one thing, but at least there are reasons for
it. I can't think of any benefits from doing the reverse.
Rich
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Tightly-coupled core distro
2012-11-18 15:16 ` Samuli Suominen
` (2 preceding siblings ...)
2012-11-18 15:34 ` Vadim A. Misbakh-Soloviov
@ 2012-11-19 13:07 ` Steven J. Long
2012-11-19 16:32 ` Alec Warner
2012-11-19 17:43 ` [gentoo-dev] " Peter Stuge
3 siblings, 2 replies; 111+ messages in thread
From: Steven J. Long @ 2012-11-19 13:07 UTC (permalink / raw
To: gentoo-dev
On Sun, Nov 18, 2012 at 05:16:18PM +0200, Samuli Suominen wrote:
> I'm still happy enough with building udev out from systemd tree and
> letting sep. /usr consept from 90s to finally die in favour of
> simplifying the system.
It's from a lot earlier than the 90s. Perhaps we should get rid of pipes,
too- they're /so/ 1970s.
Torvalds expressed it well[1]:
You made the statement that you want to get away from 30 years of
history, but the fact is, "30 years of history" is a damn good argument
for "that thing worked".
> The BIOSes have been upgraded last century to support booting from
> larger partitions, the need has long past.
> Nobody has ever provided a valid reason for using sep. /usr in the ML
> either.
>
So at the same time as you have never heard a valid reason, the need (which
you have never understood) is long past? Pfft.
To reiterate again: many of us are used to keeping /usr on a separate
partition for security and backup purposes (other use-cases for a separate
partition include mounting /usr over NFS, or a common partition for
virtual machines.) I'm sure other people would have more. Irrespective,
it should be about mechanism, not policy, and certainly not about breaking
existing setups.
Many of the advertised benefits of the "merge /bin and /sbin to /usr"
concept are in fact just benefits of having a separate /usr partition,
though of course they're presented as new and unique to the merge. So, if
you accept those as benefits, you cannot logically deny them as benefits of
a traditional /usr split.
Further, as one user pointed out[2]:
"I'd be more likely to just stick /usr back on / than create an initramfs
- it was only because the LVM guide recommended that /usr go on its own
partition that I now face this situation."
We were given a simple requirement ages ago: udev requires /usr and
/var (and going forward may require /opt for 3rd party drivers) mounted
before it starts, not for udev itself but for helper scripts that it may
call. Why get bogged down in anything else?
The recommended (which became "supported") method to do this was
to use an initramfs, since apparently any chicken-and-egg problems (such
as requiring a udev-initiated device to mount /usr) are easier to handle
there. (Note that no-one has ever provided a description of how they did
that, eg for their bluetooth keyboard, so that the issues, and how they
are addressed, could be made more transparent to everyone.)
A few us are happily running initramfs-less machines by fulfilling the
requirement with a couple of patches to openrc initscripts[2]. (It's
been working fine here since last August.) This works in the case where
you didn't need an initramfs before, ie have modules for local-disks and
filesystems built-in, root not on LVM or encrypted, but other partitions
might be-- which includes LVM users who followed the Gentoo docs.
If that's not enough, there is *already* a forked udev version which quite
a few users have been using[3] and reporting success with. I'd hope the
new fork would just collaborate with them, but it's entirely up to them
what they do.
All of this argues that, irrespective of your views of the layouts admins
prefer to use, they will still use them regardless, and indeed users will
put in the work you yourself told them to.[4] I really don't understand
why people are getting beat up on, just for going ahead and doing what
they've been told to: provide code for an alternative.
If a Gentoo developer doesn't understand what a Gentoo project means,
that's his problem. Nor should Gentoo projects suddenly change what they
are because "the internet" doesn't understand them. That's a ridiculous
basis for any change.
The thing none of the proponents of an initramfs, with no other support
for a separate /usr (apart from busybox sep /usr which does NOT fulfil the
requirements presented by Chainsaw, which Council voted to approve before:
for a start it doesn't handle /usr on LVM), have ever answered is:
How do you deal with the mismatch problem?
That is, when you have programs or libs upgraded, just as part of normal
system upgrades, and they are now different, potentially incompatible, to
the initramfs. (The potential exists, therefore it must be addressed for
a solution even to be considered as robust.)
Do you now need another script to run after every emerge to check that
files in your initramfs are in sync? After all, we've been told the
initramfs is "the new root": iow that we should think of it as our rescue
system, so this matters.
At the same time, we've been told "it's only a few hundred kilobytes at
most." That contradiction has never been answered, either.
[1] http://lwn.net/Articles/492134/
[2] http://forums.gentoo.org/viewtopic-t-901206.html
[3] http://forums.gentoo.org/viewtopic-t-934678.html
[4] http://forums.gentoo.org/viewtopic-p-6987380.html#6987380
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
2012-11-19 8:20 ` Vadim A. Misbakh-Soloviov
2012-11-19 12:14 ` Rich Freeman
@ 2012-11-19 13:08 ` Fabian Groffen
1 sibling, 0 replies; 111+ messages in thread
From: Fabian Groffen @ 2012-11-19 13:08 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
On 19-11-2012 15:20:56 +0700, Vadim A. Misbakh-Soloviov wrote:
> 18.11.2012 22:51, Fabian Groffen пишет:
> > You end up with a symlink (e.g. bin -> ./usr/bin) from one place to the
> > other regardless, so it doesn't matter much.
>
> So, why not to make /usr/bin -> ../bin (or, maybe even /usr/bin -> /bin
> (notice the «/»)) ? :D
Dunno if Linux has a way to, but if you use an alternative mountpoint,
it's nice when the symlink points in the right direction, and not
accidentially to a life filesystem coming from a rescue device or
whatever.
Fabian
--
Fabian Groffen
Gentoo on a different level
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Tightly-coupled core distro
2012-11-19 13:07 ` [gentoo-dev] Re: Tightly-coupled core distro Steven J. Long
@ 2012-11-19 16:32 ` Alec Warner
2012-11-19 16:52 ` Rich Freeman
2012-11-19 17:43 ` [gentoo-dev] " Peter Stuge
1 sibling, 1 reply; 111+ messages in thread
From: Alec Warner @ 2012-11-19 16:32 UTC (permalink / raw
To: gentoo-dev
On Mon, Nov 19, 2012 at 5:07 AM, Steven J. Long
<slong@rathaus.eclipse.co.uk> wrote:
> On Sun, Nov 18, 2012 at 05:16:18PM +0200, Samuli Suominen wrote:
>> I'm still happy enough with building udev out from systemd tree and
>> letting sep. /usr consept from 90s to finally die in favour of
>> simplifying the system.
>
> It's from a lot earlier than the 90s. Perhaps we should get rid of pipes,
> too- they're /so/ 1970s.
>
> Torvalds expressed it well[1]:
> You made the statement that you want to get away from 30 years of
> history, but the fact is, "30 years of history" is a damn good argument
> for "that thing worked".
>
>> The BIOSes have been upgraded last century to support booting from
>> larger partitions, the need has long past.
>> Nobody has ever provided a valid reason for using sep. /usr in the ML
>> either.
>>
> So at the same time as you have never heard a valid reason, the need (which
> you have never understood) is long past? Pfft.
>
> To reiterate again: many of us are used to keeping /usr on a separate
> partition for security and backup purposes (other use-cases for a separate
> partition include mounting /usr over NFS, or a common partition for
> virtual machines.) I'm sure other people would have more. Irrespective,
> it should be about mechanism, not policy, and certainly not about breaking
> existing setups.
>
> Many of the advertised benefits of the "merge /bin and /sbin to /usr"
> concept are in fact just benefits of having a separate /usr partition,
> though of course they're presented as new and unique to the merge. So, if
> you accept those as benefits, you cannot logically deny them as benefits of
> a traditional /usr split.
>
> Further, as one user pointed out[2]:
> "I'd be more likely to just stick /usr back on / than create an initramfs
> - it was only because the LVM guide recommended that /usr go on its own
> partition that I now face this situation."
>
> We were given a simple requirement ages ago: udev requires /usr and
> /var (and going forward may require /opt for 3rd party drivers) mounted
> before it starts, not for udev itself but for helper scripts that it may
> call. Why get bogged down in anything else?
>
> The recommended (which became "supported") method to do this was
> to use an initramfs, since apparently any chicken-and-egg problems (such
> as requiring a udev-initiated device to mount /usr) are easier to handle
> there. (Note that no-one has ever provided a description of how they did
> that, eg for their bluetooth keyboard, so that the issues, and how they
> are addressed, could be made more transparent to everyone.)
>
> A few us are happily running initramfs-less machines by fulfilling the
> requirement with a couple of patches to openrc initscripts[2]. (It's
> been working fine here since last August.) This works in the case where
> you didn't need an initramfs before, ie have modules for local-disks and
> filesystems built-in, root not on LVM or encrypted, but other partitions
> might be-- which includes LVM users who followed the Gentoo docs.
>
> If that's not enough, there is *already* a forked udev version which quite
> a few users have been using[3] and reporting success with. I'd hope the
> new fork would just collaborate with them, but it's entirely up to them
> what they do.
>
> All of this argues that, irrespective of your views of the layouts admins
> prefer to use, they will still use them regardless, and indeed users will
> put in the work you yourself told them to.[4] I really don't understand
> why people are getting beat up on, just for going ahead and doing what
> they've been told to: provide code for an alternative.
>
> If a Gentoo developer doesn't understand what a Gentoo project means,
> that's his problem. Nor should Gentoo projects suddenly change what they
> are because "the internet" doesn't understand them. That's a ridiculous
> basis for any change.
>
> The thing none of the proponents of an initramfs, with no other support
> for a separate /usr (apart from busybox sep /usr which does NOT fulfil the
> requirements presented by Chainsaw, which Council voted to approve before:
> for a start it doesn't handle /usr on LVM), have ever answered is:
>
> How do you deal with the mismatch problem?
>
> That is, when you have programs or libs upgraded, just as part of normal
> system upgrades, and they are now different, potentially incompatible, to
> the initramfs. (The potential exists, therefore it must be addressed for
> a solution even to be considered as robust.)
>
> Do you now need another script to run after every emerge to check that
> files in your initramfs are in sync? After all, we've been told the
> initramfs is "the new root": iow that we should think of it as our rescue
> system, so this matters.
Debian / Ubuntu have a tool that basically does this. Its
update-initramfs. I believe it is called from..the postinst of
packages that are supposed to be in the initramfs? honestly I'd have
to look up how they implemented it.
-A
>
> At the same time, we've been told "it's only a few hundred kilobytes at
> most." That contradiction has never been answered, either.
>
> [1] http://lwn.net/Articles/492134/
> [2] http://forums.gentoo.org/viewtopic-t-901206.html
> [3] http://forums.gentoo.org/viewtopic-t-934678.html
> [4] http://forums.gentoo.org/viewtopic-p-6987380.html#6987380
> --
> #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
>
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Tightly-coupled core distro
2012-11-19 16:32 ` Alec Warner
@ 2012-11-19 16:52 ` Rich Freeman
2012-11-19 16:54 ` Diego Elio Pettenò
2012-11-27 8:11 ` [gentoo-dev] " Steven J. Long
0 siblings, 2 replies; 111+ messages in thread
From: Rich Freeman @ 2012-11-19 16:52 UTC (permalink / raw
To: gentoo-dev
On Mon, Nov 19, 2012 at 11:32 AM, Alec Warner <antarus@gentoo.org> wrote:
>
> Debian / Ubuntu have a tool that basically does this. Its
> update-initramfs. I believe it is called from..the postinst of
> packages that are supposed to be in the initramfs? honestly I'd have
> to look up how they implemented it.
Not a bad idea, with a corresponding eselect tool to control what kind
of initramfs you have (dracut, genkernel, none,
remind-me-but-I-roll-my-own, etc). The ebuild would just call the
function, and the function would handle it accordingly.
Rich
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Tightly-coupled core distro
2012-11-19 16:52 ` Rich Freeman
@ 2012-11-19 16:54 ` Diego Elio Pettenò
2012-11-27 8:11 ` [gentoo-dev] " Steven J. Long
1 sibling, 0 replies; 111+ messages in thread
From: Diego Elio Pettenò @ 2012-11-19 16:54 UTC (permalink / raw
To: gentoo-dev
On 19/11/2012 08:52, Rich Freeman wrote:
> Not a bad idea, with a corresponding eselect tool to control what kind
> of initramfs you have (dracut, genkernel, none,
> remind-me-but-I-roll-my-own, etc). The ebuild would just call the
> function, and the function would handle it accordingly.
Glad to hear we're now addressing the problem from the technical
prospective.
Thanks Rich,
--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Tightly-coupled core distro
2012-11-19 13:07 ` [gentoo-dev] Re: Tightly-coupled core distro Steven J. Long
2012-11-19 16:32 ` Alec Warner
@ 2012-11-19 17:43 ` Peter Stuge
2012-11-19 18:16 ` Rich Freeman
1 sibling, 1 reply; 111+ messages in thread
From: Peter Stuge @ 2012-11-19 17:43 UTC (permalink / raw
To: gentoo-dev
Steven J. Long wrote:
> Nor should Gentoo projects suddenly change what they are because
> "the internet" doesn't understand them. That's a ridiculous basis
> for any change.
If a friend whom I care about and respect tells me that they don't
understand something I do then I try to consider if maybe I should
change my ways.
If the internet tells me, then even though I probably don't care
about them I might still consider a change, because of the numbers.
It doesn't always matter what others think, but it is always worth
considering. It matters a lot for how one is understood.
//Peter
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Tightly-coupled core distro
2012-11-19 17:43 ` [gentoo-dev] " Peter Stuge
@ 2012-11-19 18:16 ` Rich Freeman
2012-11-19 18:33 ` Peter Stuge
0 siblings, 1 reply; 111+ messages in thread
From: Rich Freeman @ 2012-11-19 18:16 UTC (permalink / raw
To: gentoo-dev
On Mon, Nov 19, 2012 at 12:43 PM, Peter Stuge <peter@stuge.se> wrote:
> Steven J. Long wrote:
>> Nor should Gentoo projects suddenly change what they are because
>> "the internet" doesn't understand them. That's a ridiculous basis
>> for any change.
>
> It doesn't always matter what others think, but it is always worth
> considering. It matters a lot for how one is understood.
Sure, but what's the alternative? GLEP-39 was written precisely
because a more top-down system wasn't really working well.
The new model is much more bazar-like, with the Council as a forum for
appeal if things get out of hand.
If once in a while we have to deal with the fallout of something like
this I'll take that any day if it makes it more likely for the next
X32/Prefix/etc to take off on Gentoo.
Rich
^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: [gentoo-dev] Re: Tightly-coupled core distro
2012-11-19 18:16 ` Rich Freeman
@ 2012-11-19 18:33 ` Peter Stuge
0 siblings, 0 replies; 111+ messages in thread
From: Peter Stuge @ 2012-11-19 18:33 UTC (permalink / raw
To: gentoo-dev
Rich Freeman wrote:
> >> Nor should Gentoo projects suddenly change what they are because
> >> "the internet" doesn't understand them. That's a ridiculous basis
> >> for any change.
> >
> > It doesn't always matter what others think, but it is always worth
> > considering. It matters a lot for how one is understood.
>
> Sure, but what's the alternative? GLEP-39 was written precisely
> because a more top-down system wasn't really working well.
I'm thinking that perhaps sunrise projects could be useful. It would
be up to each developer if they choose to start their project as a
"normal" project, or as a sunrise project. It could just as well be
called bootstrap or experimental or one of many other fine names.
There would not be much difference between the two, other than
perhaps that they are hosted in different places to more clearly
communicate intent of the developers who work on the project.
It would also be up to developers if they want to move their project
between the two "types".
> The new model is much more bazar-like, with the Council as a forum
> for appeal if things get out of hand.
They could make recommendations about where new projects should
probably start, but developers could still be free to choose the
other type.
> If once in a while we have to deal with the fallout of something
> like this I'll take that any day if it makes it more likely for the
> next X32/Prefix/etc to take off on Gentoo.
I don't think it's strictly neccessary to accept fallout from
misunderstandings just to have room for innovation.
//Peter
^ permalink raw reply [flat|nested] 111+ messages in thread
* [gentoo-dev] Re: Re: Tightly-coupled core distro
2012-11-19 16:52 ` Rich Freeman
2012-11-19 16:54 ` Diego Elio Pettenò
@ 2012-11-27 8:11 ` Steven J. Long
1 sibling, 0 replies; 111+ messages in thread
From: Steven J. Long @ 2012-11-27 8:11 UTC (permalink / raw
To: gentoo-dev
On Mon, Nov 19, 2012 at 11:52:46AM -0500, Rich Freeman wrote:
> On Mon, Nov 19, 2012 at 11:32 AM, Alec Warner <antarus@gentoo.org> wrote:
> >
> > Debian / Ubuntu have a tool that basically does this. Its
> > update-initramfs. I believe it is called from..the postinst of
> > packages that are supposed to be in the initramfs? honestly I'd have
> > to look up how they implemented it.
>
> Not a bad idea, with a corresponding eselect tool to control what kind
> of initramfs you have (dracut, genkernel, none,
> remind-me-but-I-roll-my-own, etc). The ebuild would just call the
> function, and the function would handle it accordingly.
>
The issue there is "packages that are supposed to be in the initramfs," since
we've been told the initramfs is a custom thing for our situation. (Which is
kinda my issue with just dumping the whole problem on end-users and admins
who are not using a prepackaged distro without customisation, instead of
maintaining backward-compatibility.)
Mind, I don't have an issue with developers deciding certain packages are
critical: after all the same knowledge informs what should be on root.
I just don't think that the above answers the problem comprehensively (and
thus it isn't worth the maintenance headache, if it can be avoided.)
All the tutorials, and packages, I've seen on the forums take you through
deciding exactly what you need in the initramfs. So given that each user
has a potentially different set of stuff on there, the robust method would
appear to require the mangler to know which packages had files on there, and
to update them accordingly (or run the generation tool, or warn, as you said)
when one of that set were updated.
Simply triggering a warning when one of a named set is built, sounds like a
start. (The initramfs generation script could run qfile to build/check the
set.) Thereafter it's "just" a matter of hooking into that, if the functionality
is not already present.
(I don't run unstable portage any more, as I need to be close to what end-users
of our emerge wrapper are using, so I'm not up on the current state of 2.2. I'd
prefer not to have to script round this issue, since it doesn't affect me at all.)
Regards,
SteveL.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 111+ messages in thread
end of thread, other threads:[~2012-11-27 7:55 UTC | newest]
Thread overview: 111+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20353.41193.129711.306663@a1i15.kph.uni-mainz.de>
2012-04-08 22:04 ` [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Greg KH
2012-04-08 23:28 ` Rich Freeman
2012-04-09 18:09 ` [gentoo-dev] " Steven J Long
2012-04-09 19:20 ` Zac Medico
2012-04-11 2:28 ` [gentoo-dev] " Steven J Long
2012-04-11 4:09 ` Zac Medico
2012-04-11 5:18 ` William Hubbs
2012-04-11 16:10 ` [gentoo-dev] " Steven J Long
2012-04-28 21:09 ` Mike Frysinger
2012-05-04 16:36 ` [gentoo-dev] " Steven J Long
2012-05-04 16:47 ` Mike Frysinger
2012-05-04 17:24 ` [gentoo-dev] " Steven J Long
2012-04-11 14:13 ` [gentoo-dev] " Steven J Long
2012-04-11 19:57 ` Zac Medico
2012-04-22 2:43 ` [gentoo-dev] " Steven J Long
2012-04-22 2:53 ` Rich Freeman
2012-04-22 5:28 ` [gentoo-dev] " Steven J Long
2012-04-22 6:00 ` Mike Gilbert
2012-04-22 9:07 ` [gentoo-dev] " Ulrich Mueller
2012-04-22 9:28 ` [gentoo-dev] " Steven J Long
2012-04-22 17:55 ` Mike Gilbert
2012-04-22 18:13 ` Zac Medico
2012-05-04 15:20 ` [gentoo-dev] " Steven J Long
2012-05-04 19:50 ` Zac Medico
2012-05-04 15:10 ` Steven J Long
2012-04-22 9:11 ` [gentoo-dev] Re: Re: Re: Re: " Steven J Long
2012-04-23 1:25 ` [gentoo-dev] " Walter Dnes
2012-04-23 6:04 ` Zac Medico
2012-04-23 14:29 ` Walter Dnes
2012-04-23 6:30 ` [gentoo-dev] " Fabian Groffen
2012-05-04 14:50 ` [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] " Steven J Long
2012-05-05 1:05 ` Greg KH
2012-05-08 1:40 ` [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012] Steven J Long
2012-05-08 2:09 ` Richard Yao
2012-05-09 18:32 ` Greg KH
2012-05-09 18:51 ` Fabio Erculiani
2012-05-09 22:36 ` Greg KH
2012-05-10 1:08 ` Patrick Lauer
2012-05-10 3:08 ` Rich Freeman
2012-05-10 4:34 ` Fabio Erculiani
2012-05-10 16:54 ` Olivier Crête
2012-05-14 18:48 ` Luca Barbato
2012-05-10 23:41 ` Alec Warner
2012-05-17 4:39 ` [gentoo-dev] " Steven J Long
2012-05-10 11:44 ` [gentoo-dev] " Chí-Thanh Christopher Nguyễn
2012-05-10 14:39 ` Zac Medico
2012-05-12 0:39 ` Greg KH
2012-05-10 18:57 ` David Leverton
2012-05-10 19:22 ` Zac Medico
2012-05-10 19:30 ` David Leverton
2012-05-11 1:27 ` [gentoo-dev] " Duncan
2012-05-10 19:55 ` [gentoo-dev] " Markos Chandras
2012-05-10 19:59 ` Ciaran McCreesh
2012-05-10 20:13 ` Michał Górny
2012-05-10 20:14 ` Ciaran McCreesh
2012-05-10 20:23 ` Michał Górny
2012-05-10 20:48 ` Fabio Erculiani
2012-05-11 0:59 ` [gentoo-dev] " Duncan
2012-05-11 2:53 ` Duncan
2012-05-13 2:24 ` Walter Dnes
[not found] ` <4bdd949a377d40eb85590870be440551@HUBCAS1.cs.stonybrook.edu>
2012-11-18 7:54 ` [gentoo-dev] " Richard Yao
2012-11-18 8:08 ` Greg KH
2012-11-18 8:10 ` Richard Yao
2012-11-18 8:19 ` Greg KH
2012-11-18 8:19 ` Richard Yao
2012-11-18 8:27 ` Greg KH
2012-11-18 8:38 ` Pacho Ramos
2012-11-18 8:21 ` Diego Elio Pettenò
2012-11-18 8:49 ` Samuli Suominen
2012-11-18 11:11 ` Vadim A. Misbakh-Soloviov
2012-11-18 12:26 ` Rich Freeman
2012-11-18 16:49 ` [gentoo-dev] " Duncan
2012-11-18 15:04 ` [gentoo-dev] " Diego Elio Pettenò
2012-11-18 15:16 ` Samuli Suominen
2012-11-18 15:31 ` Diego Elio Pettenò
2012-11-18 15:32 ` Fabian Groffen
2012-11-18 15:34 ` Vadim A. Misbakh-Soloviov
2012-11-18 15:42 ` Diego Elio Pettenò
2012-11-18 15:51 ` Fabian Groffen
2012-11-19 8:20 ` Vadim A. Misbakh-Soloviov
2012-11-19 12:14 ` Rich Freeman
2012-11-19 13:08 ` Fabian Groffen
2012-11-18 15:50 ` Luca Barbato
2012-11-19 13:07 ` [gentoo-dev] Re: Tightly-coupled core distro Steven J. Long
2012-11-19 16:32 ` Alec Warner
2012-11-19 16:52 ` Rich Freeman
2012-11-19 16:54 ` Diego Elio Pettenò
2012-11-27 8:11 ` [gentoo-dev] " Steven J. Long
2012-11-19 17:43 ` [gentoo-dev] " Peter Stuge
2012-11-19 18:16 ` Rich Freeman
2012-11-19 18:33 ` Peter Stuge
2012-11-18 15:43 ` [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012] Vadim A. Misbakh-Soloviov
2012-11-18 15:47 ` Diego Elio Pettenò
2012-11-18 15:54 ` Fabian Groffen
2012-11-18 16:00 ` Diego Elio Pettenò
2012-11-18 16:14 ` Fabio Erculiani
2012-11-18 15:56 ` Luca Barbato
2012-11-18 17:19 ` [gentoo-dev] " Duncan
2012-11-18 18:15 ` Stelian Ionescu
2012-05-17 4:16 ` Steven J Long
2012-04-11 11:44 ` [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Rich Freeman
2012-04-11 15:09 ` [gentoo-dev] " Steven J Long
2012-04-11 16:55 ` Rich Freeman
2012-04-22 3:30 ` [gentoo-dev] " Steven J Long
2012-04-10 18:45 ` [gentoo-dev] " William Hubbs
2012-04-11 9:34 ` Ralph Sennhauser
2012-04-28 23:44 ` Luca Barbato
2012-04-29 6:44 ` Michał Górny
2012-04-29 7:04 ` Luca Barbato
2012-04-29 22:40 ` Zac Medico
2012-04-29 23:38 ` Luca Barbato
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox