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
signature.asc
Description: This is a digitally signed message part.
