Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-desktop
Navigation:
Lists: gentoo-desktop: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-desktop@g.o, Ladislav Láska <ladislav.laska@...>
From: Martin von Gagern <Martin.vGagern@...>
Subject: Re: kde-sunset: kdepim-kresources broken
Date: Fri, 19 Feb 2010 20:47:13 +0100
Hi there, Ladislav in particular!

On 19.02.2010 13:14, Ladislav Laska wrote:
> Yes, but that's not the problem. You see, the commit you're mentioning
> removes hack, but another hack is still present in kde-meta, which
> prevents prepare from base.eclass to be invoked (another "dummy"
> function). Removing this, only src_prepare in ebuild or in base.eclass
> can be invoked, both of them will do just fine.

I originally committed 9704c7d47bbf70ec8f3fd78fd3b00e7603dfa879 but I
fear I missed kde-meta. Thanks for noticing that, and fixing it in
ac08ab0978dd2fc7f7b078480c1c3ca5d547e058

> Unfortunately, src_prepare is eapi=2 thing, so we have to migrate all
> packages with patches to eapi 2, but this should not be a problem,
> since i've seen someone is already doing that.

I think you are wrong here: base_src_unpack will call base_src_prepare
for older EAPIs. So if we can ensure that every eclass delegates to
base_src_prepare in the end, or to something that does handle PATCHES,
then everything should be all right.

> Anyway, I'll commit patch which will at least fix things for eapi 2.

Do you mean 477d925cbe9096c75c88ef1dea0b74c666ffd363 and friends? I must
confess, I don't fully understand your intention here. We currently have
the following code in kde_src_unpack:

[[ -d "${KDE_S}" ]] || base_src_unpack unpack
...
# Check for PATCHES in EAPI=0|1
case ${EAPI:-0} in
	0|1)
		if [[ -n ${PATCHES} ]]; then
			[[ -d "${KDE_S}" ]] || base_src_prepare	
		fi
	;;
esac

The base_src_unpack invokation makes sense: unpack unless the source dir
already exists. base_src_unpack will call base_src_prepare as explained
above, so in my opinion, that additional code further down shouldn't
ever be necessary, unless an ebuild decides to unpack archives by
itself, in which case it is in my opinion responsible for patching as
well, e.g. by using base_src_unpack for unpacking.

But what I understand even less is the condition. Prepare if the source
dir still does not exist after unpacking??? What's the sense here?
Seeing that the first thing base_src_prepare does is cd into $S, that
doesn't seem to make a lot of sense for the $KDE_S == $S case. And for
other cases, I still doubt that patching $S will create the $KDE_S dir.

Please explain your rationale, or remove that case...esac code if you
added it in error. If you were working on a particular package when
writing that code, let me know what it was, and have a look at a build
with ECLASS_DEBUG_OUTPUT=on to see whether that code you added was
actually used the way you expected it to.

Greetings,
 Martin

Attachment:
signature.asc (OpenPGP digital signature)
References:
kde-sunset: kdepim-kresources broken
-- Roman
Re: kde-sunset: kdepim-kresources broken
-- Chris Bandy
Re: kde-sunset: kdepim-kresources broken
-- Ladislav Laska
Re: kde-sunset: kdepim-kresources broken
-- Roman
Re: kde-sunset: kdepim-kresources broken
-- Ladislav Laska
Re: kde-sunset: kdepim-kresources broken
-- Chris Bandy
Re: kde-sunset: kdepim-kresources broken
-- Chris Bandy
Re: kde-sunset: kdepim-kresources broken
-- Ladislav Laska
Navigation:
Lists: gentoo-desktop: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: kde-sunset: kdepim-kresources broken
Next by thread:
KDE 4.4: where is Knetworkmanager and Network Manager Plasmoid?
Previous by date:
Re: kde-sunset: kdepim-kresources broken
Next by date:
kde-sunset: Calling base_src_prepare from kde.eclass


Updated Jun 28, 2012

Summary: Archive of the gentoo-desktop mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.