Description of problem: I have been wondering if we should not introduce ConditionArch= for units to overcome installer limitation ( in our ( fedora ) case anaconda/yum not honouring arch= in comps ). This would also allow for arch specific daemons to be enabled by default in preset ( like for example that iprutils mess ) along with bringing the flexibility to activate or deactivating additional units if on specific architecture Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please give convincing examples why this is useful beyond bad packaging. Usually, things like that should and can be solved at the packaging step not by the running system. Systemd should really not work-around possible limitations of anaconda or yum; things should be fixed where they break, not papered-over.
You might want to activate/deactivate different set or additional sets of units based on the cpu architecture you are running on but maybe the usage of such options is to far and to few that it does not warrant to be implemented. Maybe I was just looking to much into how installation might be in the future but yeah in the end this might be messy regardless of arch specific units or unit snippets
I am not totally against this, but I'd ike to hear a really strong usecase for this, where doing %ifarch in the rpm spec would not be the better solution. Even bigger though is the issue that we wouldn't know what actually to check for. People probably want to know whether a certain binary arch can be run or not. But checking that is incredibly hard, as this depends on the available /etc/ld.so binary loaders. Just exposing the kernel arch won't cut it, as for example an x86-64 kernel supports both i386 and x86-64 binaries.
(In reply to Lennart Poettering from comment #3) > I am not totally against this, but I'd ike to hear a really strong usecase > for this, where doing %ifarch in the rpm spec would not be the better > solution. For the first ifarch only applies to rpm ( and would think installer/updates of the future would flash stuff ) and secondly I've try to explain the usecases for this in comment 2 > Even bigger though is the issue that we wouldn't know what actually to check > for. People probably want to know whether a certain binary arch can be run > or not. But checking that is incredibly hard, as this depends on the > available /etc/ld.so binary loaders. Just exposing the kernel arch won't cut > it, as for example an x86-64 kernel supports both i386 and x86-64 binaries. Not following I would say this is for everything but those kernel arch "i386 x86-64" ( and if not loading just check for ConditionArch !=i386 ) as in this would only apply for ppc,sparc,arm etc. But I'm afraid as Kay points out when we are doing this we are working around some other issues and if you guy's dont see the need for this then let's just close this and re-open if and when we come across concrete usecase(s)
We discuss this at the hackfest and this is to much of a corner case to be implemented hence closing