On Tue, 26.03.13 14:17, Bill Nottingham (nott...@redhat.com) wrote: > > Lukas Nykryn (lnyk...@redhat.com) said: > > --- > > TODO | 2 -- > > man/systemd.unit.xml.in | 8 ++++++++ > > src/core/condition.c | 16 ++++++++++++++++ > > src/core/condition.h | 1 + > > src/core/load-fragment-gperf.gperf.m4 | 1 + > > 5 files changed, 26 insertions(+), 2 deletions(-) > > Not that this seems wrong, but what is the usage case for this that > can't be solved via package (de)installation?
That's what I thought too at first. This feature request came from the anaconda folks who want to conditionalize a few units for s390, i.e. weird console support and things, and honestly, I can see why they prefer solving this like this rather than with a build time thing. I am not entirely sure whether this should check the kernel architecture however, or the userspace architecture. Lukas patch currently checks the kernel reported architecture, i.e. regardless whether you run a 32bit or 64bit userspace, as long as you run a 64bit kernel you will get a 64bit arch... So not sure what we want here. a) the userspace arch (which would probably effectively mean the arch systemd itself is compiled for, i.e. systemd's build arch) b) the kernelspace arch (i.e. uname()). c) both in some way? Ideas? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
