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! |