Bug 974758 - RFE: Introduce ConditionArch=
RFE: Introduce ConditionArch=
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2013-06-15 10:28 EDT by Jóhann B. Guðmundsson
Modified: 2013-08-21 06:26 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-21 06:26:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jóhann B. Guðmundsson 2013-06-15 10:28:05 EDT
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:
Comment 1 Kay Sievers 2013-06-17 17:17:36 EDT
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.
Comment 2 Jóhann B. Guðmundsson 2013-06-17 18:08:42 EDT
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
Comment 3 Lennart Poettering 2013-06-19 09:46:17 EDT
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.
Comment 4 Jóhann B. Guðmundsson 2013-06-19 10:21:36 EDT
(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)
Comment 5 Jóhann B. Guðmundsson 2013-08-21 06:26:39 EDT
We discuss this at the hackfest and this is to much of a corner case to be implemented hence closing

Note You need to log in before you can comment on or make changes to this bug.