Re: [gentoo-user] KDE 3.5.10 in portage...

[Bo Ørsted Andresen]

On Sunday 14 September 2008 22:37:21 Volker Armin Hemmann wrote:
> > > Making the 'official' overlay paludis-only was a BIG mistake.
> >
> > It's not "paludis-only", it will work with any package manager whose
> > developers care enough to support the useful features of the kdebuild-1
> > EAPI.
>
> and that was an official api? Yes? No?

Official according to whom? It is a stable and well documented eapi that any 
package manager that regards those features to be useful can implement.

> Was it needed? No - proven by kdesvn-portage

And noone ever claimed otherwise.

[...]
> > The KDE overlay isn't produced by the "paludis-group".
>
> no, it was just made by vivid paludis fans. Hey, lets make an overlay a lot
> of user want - and make it paludis only. That way we can push paludis!

Wow. What do you base this nonsense on?

> > No, to provide ebuilds that make use of useful features that benefit both
> > users and developers.
>
> which one? Which features 'benefit both users and developers' and are sooo
> important that the kde overlay had to be paludis only?
>
> Name them please.

- '-scm' support (--dl-reinstall-scm for users)
- use dependencies (no surprising interruptions mid-merge)
- suggestions (you see them upfront rather than in elog messages afterwards)
- sets

The latter of these is not subject to eapi but incredibly useful when dealing 
with huge amounts of packages. It obsoletes meta packages and makes 
reinstalls or uninstalls of all packages in the sets trivial. For Paludis it 
also means that you can unmask/keyword two hundred packages just by addding 
the sets to your packages.{keywords,unmask} equivalents. Both Paludis and 
Portage 2.2 now has sets support although the details of their 
implementations vary greatly.

> Oh, does paludis support and equivalent to 'keep-going' or
> '--ignore-failures' or are people who wants this extremly usefull features
> still attacked and insulted?

Paludis had --continue-on-failure long before --keep-going was implemented in 
Portage (which is months after the creation of the kdebuild overlay). This is 
also one of the advantages that users of live KDE ebuilds got by using 
Paludis (or get if you consider the additional flexibility when compared 
to --keep-going to be useful).

On Monday 15 September 2008 00:38:18 Volker Armin Hemmann wrote:
> lets see - an overlay is setup to develop and test ebuilds for KDE4 that
> should some day go into the tree.
>
> Deciding to use a feature that the official pm does not provide - and only
> one of the three makes the 'testing' part and 'for the tree' pretty
> superfluos.

And again I wonder what you base this nonsense on. Perhaps you never ever 
bothered to look at this overlay, what it provides or what the intentions 
behind it was?

As one of the original decision makers behind it I can tell you, that we never 
intended to put any of these ebuilds in the tree. For this reason it also 
never contained any release of KDE. Releases were maintained separately in 
the tree using eapi 1. It only contains live ebuilds. Which is where '-scm' 
and sets support provide the biggest advantages.

And we didn't do it to harass users. We did it because we wanted to get some 
real world experience with some of the features that Paludis had provided for 
years yet there were no indications Portage would support any time soon. Live 
KDE packages was deemed the place where adding this requirement made the most 
sense. Managing two hundred packages without those features is pain anyway.

We decided that the monthly KDE releases that we were packaging and adding to 
the main tree using eapi 1 were frequent enough for those who didn't want 
Paludis for whatever reason. If anybody disagreed with that they could 
maintain their own overlay (which they did/do). We also announced it over 
three weeks before we actually made it happen so anybody who cared about the 
live KDE ebuilds can't really complaim about having been caught by surprise.

-- 
Bo Andresen