Mailing List Archive

Fabiano Engler posted on Fri, 26 Jul 2013 22:36:08 -0300 as excerpted:

> Oh man, knowing the next release will force enable semantic desktop is
> bad news, I would surely drop KDE desktop when that became stable and I
> am forced to update.
>
> Your work offers some hope though, I think the better approach for end
> users would be a plug and play overlay, but if I haven't read it here I
> would probably not even think about looking for an overlay for this and
> would just move away, which I suspect some other users will do too..
>
> Thanks for the time and effort into sharing this, much appreciated.

Time to get rid of these old subthreads still marked to reply to later,
as events have long passed them up.

(On a personal note, work suddenly slammed me with mountains of overtime,
and while I normally update a couple times a week, I had all I could do
to update even a couple times a month for awhile. That's why my posts
here unfortunately dried up so fast. Work has slowed down to something
reasonable again, so now I have time to come back and tie up lose ends,
even if time and events /have/ rather made them anticlimatic.)

As I assume most readers have figured out by now but for the record,
gentoo/kde, to their credit, finally decided to add the semantic-desktop
USE flag back to 3.11 before it stabilized. =:^)

So ultimately, the only folks that had to deal with the situation were
those like me running in-tree unstable, or the gentoo/kde overlay with
its pre-release versions (which is where I am). And people running
~arch, and even MORE so people running overlay pre-release versions,
should be prepared to deal with this sort of thing, or they should
reevaluate their running ~arch or the overlay in the first place.

Never-the-less, it's likely that our protests did play at least a small
part in bringing the semantic-desktop back, such that it was never
removed for stable users at all. =:^)

Thanks be to the gentoo/kde dev(s) that stepped up to do the work, as
some of us users know quite well now what sort of things that involves!
=:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Michael Palimaka posted on Fri, 26 Jul 2013 23:36:59 +1000 as excerpted:

> On 26/07/2013 04:26, Duncan wrote:
>> but that doesn't take care of ebuilds hard-enabling build-time deps,
>> which then cause the build to fail when they're not found. Those hard
>> enablings must be patched out, and if that's being done, might as well
>> patch out the dependency itself at the same time.

> Which ebuilds hard-enable?

As I've said elsewhere just now, wrapping up threads long overtaken by
events that I still had marked to reply to later...

In context, I was referring to (the now dead issue of) gentoo/kde
removing USE=semantic-desktop. While the USE flag was gone, ebuilds that
had previously soft-depended on nepomuk, etc, subject to USE=semantic-
desktop, were then hard-depending on it, because the USE flag had been
removed and the dependencies hard-enabled in the ebuild.

Gentoo's package.provided could be used to "fake" the package being there
for portage, but that wouldn't help for ebuilds that hard-enabled
configure-options that had previously been enabled only with USE=semantic-
desktop, because the dependencies were now hard-dependencies coded into
the ebuild. Naturally, when those ebuilds failed to find dependencies
the hard-enabled options called for, they failed, and package.provided
wouldn't help with that.

I was simply saying that such hard-enabling had to be patched out to
avoid those failures, and since we were patching it out anyway, we might
as well patch out the entire dependency, thus avoiding the whole
package.provided hassle as well.

Happily, events overtook the thread in my absence, and gentoo/kde decided
to bring back USE=semantic-desktop before 4.11 stabilization, after all.
=:^) So now it doesn't matter. However, that /is/ what I was referring
to, as I wrap up this subthread.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Martin Vaeth posted on Thu, 18 Jul 2013 14:32:06 +0000 as excerpted:

> Why not use the script to patch the ebuilds after fetching but store the
> patched ebuilds in your dedicated overlay instead of the original
> location?
> If you give this dedicated overlay a higher priority in
> /etc/portage/repos.conf, portage will install the patched ebuilds if
> they are available.
>
> For a general framework, one could e.g. support directories of the form
>
> /etc/portage/ebuild.patches/FROM:TO/whatever

[More dead thread wrapup]

Just bumping this as an idea to followup on, in case there's interest in
continuing framework development in other subthread replies.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman