Re: [gentoo-dev] systemd team consensus?

[Rick \\\"Zero_Chaos\\\" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/11/2013 04:30 PM, Michał Górny wrote:
> Dnia 2013-08-11, o godz. 20:59:01
> Tom Wijsman <TomWij@g.o> napisał(a):
>
>> On Sun, 11 Aug 2013 13:29:16 -0500
>> William Hubbs <williamh@g.o> wrote:
>>
>>> I am splitting this to a separate thread, because it could become a
>>> long thread pretty easily.
>>>
>>> On Sun, Aug 11, 2013 at 07:14:00AM -0400, Rich Freeman wrote:
>>>> On Sun, Aug 11, 2013 at 3:51 AM, Samuli Suominen
>>>> <ssuominen@g.o> wrote:
>>>>> I've been considering packaging systemd in sys-fs/udev with
>>>>> USE="systemd" and use of 'if' and 'else' plus creating
>>>>> virtual/systemd for proper / installation and some other minor,
>>>>> but bad design choices done in the systemd packaging
>>>>
>>>> What is the consensus of the systemd team regarding those choices?
>>>> Would it make more sense to just fix the packaging rather than
>>>> forking it?  I'm not sure what all the issues are, or how
>>>> widespread the disagreement is.
>>>
>>> I am a member of the systemd team, and I know what needs to be done. I
>>> have offered patches multiple times the last few months to fix the
>>> packaging, only to have them refused,
>>
>> Why were they refused?
>
> Because it introduced QA violations and unnecessary backwards migration
> for our users. I'm not really into moving files every second month,
> and so far the main argument was 'I have the citation here'.
>
>>> even though I have presented,
>>> multiple times, strong recommendations from systemd upstream that I am
>>> correct, as well as making it clear that I would take responsibility
>>> for breakages the change would cause. Originally, we did install
>>> systemd correctly, but that was changed some time back,
>>
>> Why was it changed?
>
> Because systemd executables linked to a number of libraries in /usr
> and moving those libraries to rootfs is not really an option. systemd
> officially doesn't support running with separate /usr not mounted
> at boot, and there's no point to pollute rootfs with a dozen
> of late-use libraries.
>
>>> before I
>>> joined the team. All Samuli and I have asked is that the change we
>>> made that puts everything in /usr be undone.
>>
>> Why is the change refused to be undone?
>
> Why should it be undone? Changing things back to a broken state is
> called a regression.

If upstream doesn't support something it's not a regression.  This
upstream removes features all the time in the name of progress.  Either
get on the train or get run over by it.  If /usr isn't mounted at boot
then systemd team doesn't what your system to boot, so either don't run
systemd or catch up with the rest of the world and learn what an
initramfs is.

- -Zero
>
>>> You may ask why I have offered patches instead of just fixing the
>>> ebuild since I am a team member. That is because even team members
>>> aren't allowed to touch bugs assigned to systemd@g.o [1],
>>
>> Well, if there are conflicts within a team then I can agree that no
>> member is allowed to touch the bug without a collaborative decision;
>> but from what it appears this bug has been handed in a way that one
>> member appears to take all decisions and the other member has nothing
>> to say. In particular, comments 5 and 11 change the state of the bug
>> without giving any reasoning about why that change in state was made;
>> this is unacceptable, it gives us no reason to believe the state change.
>>
>> For what reason did these specific state changes happen to this bug?
>
> Because I am *really* tired of replying to the same request over
> and over again. WilliamH is continuously bombarding me with the same
> request on mail, IRC, bugzilla and mailing lists. And almost every time
> he pretends that I hadn't given him any arguments.
>
>>> my personal efforts to advocate for this specific change got me this
>>> comment as well [2]. This bug, and others like it, would never have
>>> come up if we were installing systemd the way upstream recommends.
>>
>> Why was the / -> /usr change so necessary that it causes bugs like this?
>
> Installation in a different prefix doesn't *cause* bugs. In the worst
> case, it triggers them. Bug was reported upstream and fixed. Upstream
> didn't doubt this is their fault.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSDa7YAAoJEKXdFCfdEflKVjAQAKcSbuo6aG4zk83tyOE80t80
woin3mxHIuN8x7smp7/qa8mXEeTHMnnlROIr8VbZDwz3S9e2ewfS34MM9R7ZrjLX
VKFNGNfcTmwdqREIpuqthq309DP0NUjf3j3GnzQvyukVjbmshoZbd6pvVwxFfQJq
OiGmL9e2v2IUnjrZvnytMIKHvdPCrYjhvRKu8afUUPgNAbd6PasO8jM0Hwo/n46V
egOt6KpAnC5dS35mKWp32NKdKMQm4eMuwWlbRXWolX/9RheJnw9cKYPkqE0JiRPR
17SKq8NBXnuTaJ++MbOh5JTLr8BOaBaxo0I8kjnsjDIbR84/wEkomCXv9YK5EO35
f4Pz3iMxbXVW4LrKHRRikD7IYCaekPnZz0adISPRqdrfJbnY7WYIt2CDPD+dolLc
HEyo2+11hq8XrbmYB96dObF4jmW4fSV5NUBsP3d0RZyHpD8snGy3XgVJQWmXJ+LO
CGq4WQk6ZMnNKb8jjNn5e79aC5YUL9Z9u+sDHz1ku8LQZaNiqRAN10QPIENcLH7S
6Ox5j5j7XtuPFKFe8rd+uFCyoqbq0zXpiPg39k/lxvd+RkGSJuVuSCD0/9aHCCI5
tyFLUiAk0pNQVTiXJbBbGTrTiAj4YC5MRreyVCC8j0o4FnEyHi692ozH3rchRQwM
ou3LocIAOfycJm2nd1O2
=WA4U
-----END PGP SIGNATURE-----