> > > If that 900 line diff is 'drop kdebuild', I suggest you don't
> > > bother.
> > Actually, I think that this would be a good idea. kdebuild was never
> > used in the main tree
> But it was an official Gentoo project, and it was used in a repository
> run by the Gentoo KDE team.
So the Gentoo KDE team could decide to keep the documentation. As
representative of the KDE team I say that we have no interest in keeping this
historical error around any more. Especially as it never worked (well, not
with portage at least), so none of our users would be affected.
Also, it was only official in the sense that the KDE team decided to start it,
then abandon it and leave Gentoo. In the same sense package.mask as a
directory is officially supported (used by the KDE team, temporarily removed
for legacy package managers).
> Remember that EAPI support is needed to be
> able to uninstall a package that was installed with a particular EAPI,
> so EAPIs can't be removed even when they're no longer in use.
Yeah, like, uhm, yeah, no. See above.
> > and the conditionals needed for it only add
> > clutter that makes reading and editing the source more difficult.
> Ok, so we remove the conditionals and just keep it in unconditionally.
That would imply having it in the official version, which explicitly goes
against a prior council decision.
Remember the bash 3.0/3.2 change yesterday? Where you said you don't have the
power to change it? Yeah, neither do you have it here ... adding kdebuild-1
unconditionally is not an option.
> Keeping it documented hurts no-one.
I disagree. It makes accidental errors more likely (like having kdebuild
enabled in a version that looks authorative) and makes editing a pain because
most tables are redundant (in the sense that they aren't needed and in the
sense that they are there twice to accomodate the kdebuild phantom)
It also doesn't document anything that is related to the main gentoo tree, so
it makes no sense to keep it in the document that is supposed to document
> It also reduces the amount of work
> we have to do as features that it has slowly end up in
> Portage-supported EAPIs -- EAPI 3 would have taken much longer had we
> had to rewrite it all from scratch.
That assumes that there's any overlap between future EAPIs and kdebuild, which
is quite optimistic.
So I say tag it and remove it, if anyone should be interested in archaeology
(s)he can find the right point in the git repo easily and create a
historically accurate representation of the Tyrannosaurus Rex. Err,
Have a nice day,