Gentoo Archives: gentoo-user

From: cuciferus@×××××.com
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] KDE 3.5.10 in portage...
Date: Tue, 16 Sep 2008 20:02:04
Message-Id: 200809162301.59558.cuciferus@gmail.com
In Reply to: Re: [gentoo-user] KDE 3.5.10 in portage... by "Bo Ørsted Andresen"
1 On Tuesday 16 September 2008 21:04:11 Bo Ørsted Andresen wrote:
2 > On Sunday 14 September 2008 22:37:21 Volker Armin Hemmann wrote:
3 > > > > Making the 'official' overlay paludis-only was a BIG mistake.
4 > > >
5 > > > It's not "paludis-only", it will work with any package manager whose
6 > > > developers care enough to support the useful features of the kdebuild-1
7 > > > EAPI.
8 > >
9 > > and that was an official api? Yes? No?
10 >
11 > Official according to whom? It is a stable and well documented eapi that
12 > any package manager that regards those features to be useful can implement.
13 >
14 > > Was it needed? No - proven by kdesvn-portage
15 >
16 > And noone ever claimed otherwise.
17 >
18 > [...]
19 >
20 > > > The KDE overlay isn't produced by the "paludis-group".
21 > >
22 > > no, it was just made by vivid paludis fans. Hey, lets make an overlay a
23 > > lot of user want - and make it paludis only. That way we can push
24 > > paludis!
25 >
26 > Wow. What do you base this nonsense on?
27 >
28 > > > No, to provide ebuilds that make use of useful features that benefit
29 > > > both users and developers.
30 > >
31 > > which one? Which features 'benefit both users and developers' and are
32 > > sooo important that the kde overlay had to be paludis only?
33 > >
34 > > Name them please.
35 >
36 > - '-scm' support (--dl-reinstall-scm for users)
37 > - use dependencies (no surprising interruptions mid-merge)
38 > - suggestions (you see them upfront rather than in elog messages
39 > afterwards) - sets
40 >
41 > The latter of these is not subject to eapi but incredibly useful when
42 > dealing with huge amounts of packages. It obsoletes meta packages and makes
43 > reinstalls or uninstalls of all packages in the sets trivial. For Paludis
44 > it also means that you can unmask/keyword two hundred packages just by
45 > addding the sets to your packages.{keywords,unmask} equivalents. Both
46 > Paludis and Portage 2.2 now has sets support although the details of their
47 > implementations vary greatly.
48 >
49 > > Oh, does paludis support and equivalent to 'keep-going' or
50 > > '--ignore-failures' or are people who wants this extremly usefull
51 > > features still attacked and insulted?
52 >
53 > Paludis had --continue-on-failure long before --keep-going was implemented
54 > in Portage (which is months after the creation of the kdebuild overlay).
55 > This is also one of the advantages that users of live KDE ebuilds got by
56 > using Paludis (or get if you consider the additional flexibility when
57 > compared to --keep-going to be useful).
58 >
59 > On Monday 15 September 2008 00:38:18 Volker Armin Hemmann wrote:
60 > > lets see - an overlay is setup to develop and test ebuilds for KDE4 that
61 > > should some day go into the tree.
62 > >
63 > > Deciding to use a feature that the official pm does not provide - and
64 > > only one of the three makes the 'testing' part and 'for the tree' pretty
65 > > superfluos.
66 >
67 > And again I wonder what you base this nonsense on. Perhaps you never ever
68 > bothered to look at this overlay, what it provides or what the intentions
69 > behind it was?
70 >
71 > As one of the original decision makers behind it I can tell you, that we
72 > never intended to put any of these ebuilds in the tree. For this reason it
73 > also never contained any release of KDE. Releases were maintained
74 > separately in the tree using eapi 1. It only contains live ebuilds. Which
75 > is where '-scm' and sets support provide the biggest advantages.
76 >
77 > And we didn't do it to harass users. We did it because we wanted to get
78 > some real world experience with some of the features that Paludis had
79 > provided for years yet there were no indications Portage would support any
80 > time soon. Live KDE packages was deemed the place where adding this
81 > requirement made the most sense. Managing two hundred packages without
82 > those features is pain anyway.
83 >
84 > We decided that the monthly KDE releases that we were packaging and adding
85 > to the main tree using eapi 1 were frequent enough for those who didn't
86 > want Paludis for whatever reason. If anybody disagreed with that they could
87 > maintain their own overlay (which they did/do). We also announced it over
88 > three weeks before we actually made it happen so anybody who cared about
89 > the live KDE ebuilds can't really complaim about having been caught by
90 > surprise.
91 Actually on that I can rely. I've been using the kde-svn back when it was
92 portage "allowed", and I must say it has been an improvement switching to
93 paludis. As a user I find --continue-on-failure much better and flexible than
94 --skip-first and on a "live" scm tree as this overlay has it is much needed.(
95 I don't know about --keep-going since it has been implemented only after I've
96 switched to paludis). I like paludis and it's my choise to use it. To each his
97 own.
98 Also don't flatter your selves I wouldn't(would) use a package just because
99 some dev said something about some other dev, or discard(like) it because some
100 conversation on IRC. I know what is right for me. So keep using
101 emerge/gnome/bsd whatever fits you and let's ALL continue with our lives!