Dnia 2013-08-11, o godz. 20:59:01 Tom Wijsman <[email protected]> napisał(a):
> On Sun, 11 Aug 2013 13:29:16 -0500 > William Hubbs <[email protected]> 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 > > > <[email protected]> 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. > > 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 [email protected] [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. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
