Re: [gentoo-user] Re: Circular Block? kde-env / kdelibs

[Alan McKinnon <alan@linuxholdings.co.za>]

On Wednesday 11 October 2006 23:35, Bo Ørsted Andresen wrote:
> > [nomerge      ] media-fonts/font-alias-1.0.1
> > [ebuild  N    ]   kde-base/kde-env-3-r4
> >
> > This looks for me like font-alias wants to bring in kde-env ... but
> > might be a misinterpretation from my side as well since after that
> > I decided to migrate to KDE ~x86 and since then the depenency is
> > gone.
>
> ~khelpcenter-3.5.2 pulls in ~kdelibs-3.5.2 which pulls in kde-env.
> ~kdelibs-3.5.4 on the other hand blocks kde-env. The solution is to
> add kcontrol, kicker, khelpcenter (and any other packages that still
> require a downgrade of kdelibs) to /etc/portage/package.keywords...

A further point on this topic. kde-3.5.5 just went ~x86 and I've just 
run into this blocker myself. For some reason I had kde-env in my 
world, so I looked into the ebuilds to see what's going on. kde-env 
does this:



RDEPEND="!>=kde-base/kdelibs-3.5.4-r2"

S=${WORKDIR}

src_install() {
        dodir /etc/env.d
        cat << EOF > ${D}/etc/env.d/99kde-env
KDEDIRS=/usr
CONFIG_PROTECT=/usr/share/config
#KDE_IS_PRELINKED=1
EOF
}



So it 1) blocks kdelibs-3.5.4-r2 and greater and 2) 
creates /etc/env.d/99kde-env. So far so good.

The kdelibs blocker is because of this in kdelibs-3.5.5.ebuild function 
src_install():


        cat <<EOF > "${D}"/etc/env.d/45kdepaths-${SLOT} # number goes 
down with version upgrade
PATH=${PREFIX}/bin
ROOTPATH=${PREFIX}/sbin:${PREFIX}/bin
LDPATH=${libdirs:1}
CONFIG_PROTECT="${PREFIX}/share/config ${PREFIX}/env 
${PREFIX}/shutdown /usr/share/config"
KDEDIRS="${PREFIX}:/usr:/usr/local"
#KDE_IS_PRELINKED=1
EOF


so it writes it's own 45-kdepaths-3.5 which conflicts with the same 
settings in kde-env. Fair enough and kdelibs-3.5.4-r2 is blocked for a 
similar reason. But src_install() in kdelibs-3.5.4-r1 has only:

        cat <<EOF > ${D}/etc/env.d/45kdepaths-${SLOT} # number goes down 
with version upgrade
PATH=${PREFIX}/bin
ROOTPATH=${PREFIX}/sbin:${PREFIX}/bin
LDPATH=${libdirs:1}
CONFIG_PROTECT="${PREFIX}/share/config ${PREFIX}/env ${PREFIX}/shutdown"
EOF


No conflict with the settings from kde-env, so kde-env & 
kdelibs-3.5.4-r1 work together. What's so special about 
kdelibs-3.5.4-r2 and greater that they must supplant kde-env (apart 
from the order the files are read in /etc/env.d)?

I can't decide if this is a bug or the devs are trying stuff out. 
There's also NO bugs listed for kde-env on bugzilla, so I thought I'd 
ask here first and get some comment

alan

-- 
gentoo-user@gentoo.org mailing list