sys-apps/systemd has a dependency on intltool, which is only needed for live/git builds, not for release tarballs. intltool is used in the autotools eclass when eautoreconf is called, which only happens for the live ebuild anyway. Fixing this will reduce unnecessary dependencies. Reproducible: Always
Created attachment 370682 [details, diff] systemd_intltool_dependency.patch This patch fixes the aforementioned problem. It has been created against the sys-apps/systemd-9999.ebuild, but should apply (and be applied) to the other systemd ebuilds as well.
Created attachment 370684 [details, diff] systemd_live_dependencies.patch Pardon the spam, I just noticed, that this issue applies to multiple dependencies. I enhanced the patch to include them as well. Additionally, the gtk-docs dependency appears also to be a live dependency; however, this would require more intrusive changes to the ebuild (because gtk-doctize is called manually), which I'm not ready to propose right now.
Are you sure? sys-fs/udev has elaborate hack to avoid intltool/gettext dependency: # Remove requirements for gettext and intltool wrt bug #443028 if ! has_version dev-util/intltool && ! [[ ${PV} = 9999* ]]; then sed -i \ -e '/INTLTOOL_APPLIED_VERSION=/s:=.*:=0.40.0:' \ -e '/XML::Parser perl module is required for intltool/s|^|:|' \ configure || die eval export INTLTOOL_{EXTRACT,MERGE,UPDATE}=/bin/true eval export {MSG{FMT,MERGE},XGETTEXT}=/bin/true fi So how is this solved by just moving deps in systemd when it's the same tarball?!
Hi Samuli, you're right, I looked into it and intltool is indeed a hard builttime dependency right now. I talked to upstream, this is very likely a buildsystem bug, but I don't know yet how hard it is to fix it (intltool should be used exclusively at make dist). At the very least it will take until the next systemd release anyway. So we can't really build without intltool right know, I'll look into it to get it fixed upstream, until that, we probably should close this bug for know and I can reopen it when things move forward. Implementing a workaround like in udev could probably be done, but isn't a solution I'd prefer. Sorry for the inconvenience.
This is obsolete now as upstream don't do tarballs anymore
