On Tue, 30 Oct 2012 21:57:11 +0200
Samuli Suominen <ssuomi...@gentoo.org> wrote:
> On 30/10/12 21:56, Alexis Ballier wrote:
> > On Tue, 30 Oct 2012 19:08:39 +0000 (UTC)
> > "Samuli Suominen (ssuominen)" <ssuomi...@gentoo.org> wrote:
> >
> > [...]
> >>
> >> case ${EAPI:-0} in
> >> 0|1|2|3|4) ;;
> >> *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> >> established." esac
> >
> > sounds like a useless and annoying check for just exporting one
> > function
> >
> >>
> >> RDEPEND=""
> >
> > useless?
>
> if the ebuild is EAPI=0 or EAPI=1 then DEPEND expands to RDEPEND, so
> setting empty RDEPEND prevents that, or am I missing something?
even with eclasses and inheritence ? maybe you're right but i wouldnt
bet anything
>
> >
> >> DEPEND="virtual/pkgconfig"
> >>
> >> # @FUNCTION: _udev_get_udevdir
> >> # @INTERNAL
> >> # @DESCRIPTION:
> >> # Get unprefixed udevdir.
> >> _udev_get_udevdir() {
> >> if $($(tc-getPKG_CONFIG) --exists udev); then
> >> echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> >> udev)" else
> >> echo -n /lib/udev
> >> fi
> >> }
> >>
> >> # @FUNCTION: udev_get_udevdir
> >> # @DESCRIPTION:
> >> # Output the path for the udev directory (not including ${D}).
> >> # This function always succeeds, even if udev is not installed.
> >> # The fallback value is set to /lib/udev
> >> udev_get_udevdir() {
> >> has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> >> debug-print-function ${FUNCNAME} "${@}"
> >>
> >> echo -n "${EPREFIX}$(_udev_get_udevdir)"
> >> }
> >
> > local foo=""
> > unfold _udev_get_udevdir there, replacing 'echo -n' by foo=
> > printf ...$foo
> >
> > kill the extra internal fucntion that seems useless.
> > echo isn't really reliable for precise formatting, prefer printf
> > when it matters. (in this case it doesn't matter but seems good
> > practices)
> >
> > have you checked what is the udevdir value on prefix, if at all
> > relevant ? I fear a double prefix issue.
> >
>
> the code is more or less same as systemd.eclass has, I don't want to
> diverge too much from that since we are essentially dealing with the
> same package (tarball)
well, two bad do not make a good
consider the above remarks to apply to systemd.eclass too then, and
either explain why they're not relevant or apply them to both eclasses
if you want to avoid divergence.
