1 |
* Nirbheek Chauhan <nirbheek.chauhan@×××××.com> schrieb: |
2 |
|
3 |
> > Would be different if you'd said "we don't need to split since we |
4 |
> > have useflags" or "we want to stay as near to upstream as possible" |
5 |
> > instead of "we're not debian". Being different, just to be |
6 |
> > different is really too pubertal for me ;-o |
7 |
> > |
8 |
> |
9 |
> The person you were replying to is a Gentoo Council member, elected by |
10 |
> the very devs that run Gentoo. I believe one should try and look |
11 |
> deeper in the meaning of such a man's words before labelling them as |
12 |
> "pubertal". |
13 |
|
14 |
Well, this is my personal feeling, and this is totally independent from |
15 |
his position. |
16 |
|
17 |
I've just got headaches with this "we're not debian" argumentation. |
18 |
Surely there are technical reasons to do certain things different than |
19 |
other distros, and so we should talk about exactly about these points. |
20 |
(problem -> analyis -> solution). |
21 |
|
22 |
Just insisting on being different isn't a technical reason, just an |
23 |
pubertal behaviour (well, there are good reasons for this behaviour in |
24 |
that that age, eg. becoming independent from the parent generation). |
25 |
This reminds me on the "anti-fascist" folks here in Germany, who tend to |
26 |
define themselves on being "against fascists" and declaring everyone with |
27 |
different opponions to be one (note that Germany never had noticable fascist |
28 |
movements - we had national socialists, but that's very different ;-O) |
29 |
|
30 |
> The words of a veteran usually aren't written in blind emotion or with |
31 |
> prejudice. |
32 |
|
33 |
Might be. But in this case, I really feel different. |
34 |
|
35 |
Please let's talk about concepts and practises of other distros objectively, |
36 |
leaving out personal antipathies. Every one has different views and needs, |
37 |
and technical decisions should derive them them, not from personal taste. |
38 |
|
39 |
So for example the splitting issue has to be decided for each package. |
40 |
|
41 |
As we're currently talking about PostgreSQL, we have to look at the |
42 |
possible ways to do (or not to do) so with it and weight the pros and |
43 |
cons of the different options. |
44 |
|
45 |
This decision process should be individual to each package - there is |
46 |
no (good) universal answer. If you try to declare an universal answer |
47 |
to everyone, you get religious ;-P |
48 |
|
49 |
> > Right, binary distros have a much bigger presure on that, but this |
50 |
> > doesn't mean that splitting is always bad. |
51 |
> |
52 |
> There are specific use-cases where splitting is good, such as with |
53 |
> gstreamer, gtk-sharp, gnome-python{,-desktop,-extras} which are |
54 |
> essentially dependencies of other packages, and where built_with_use |
55 |
> checks are horrid to use. |
56 |
|
57 |
Yes, and there a lots of them. |
58 |
|
59 |
Classical example: language bindings for certain libs. They really |
60 |
should be different packages. But, of course, the fault mostly comes |
61 |
from the upstream and individual distros aren't the right place to |
62 |
fix this (again, one of the reasons why I founded the OSS-QM project). |
63 |
|
64 |
> I personally have no opinion about the -base and -server split, since |
65 |
> I do not know enough about it. But I am firmly against the -docs split |
66 |
> since the doc USE flag is for this use-case, and I see no reason why |
67 |
> not to use it. |
68 |
|
69 |
Historically, the manuals (actually, electronic books - printed out |
70 |
about 1k pages) have been an separate package from upstream. And this |
71 |
for a good reason: they an different entitiy (even maintained by |
72 |
different people), quite large and (un)related to the rest of PQ just |
73 |
like an programming book to an invidiual compiler (note that it's also |
74 |
contains of the most complete posix-SQL references in the OSS world). |
75 |
|
76 |
> Just stick a USE=doc on -base and be done with it |
77 |
|
78 |
This has an major drawback: requires to do an complete rebuild/reinstall |
79 |
of the whole package if you just need the manual. When setting up an |
80 |
new server, you normally don't need the complete manual installed |
81 |
(assuming you're already confident w/ PQ), but you need it someday |
82 |
later when you have to look up something and other media (web access |
83 |
or printed out) are not convenient/available. |
84 |
|
85 |
I, personally, don't *need* it at all, but having an separate package |
86 |
makes it more convenient. And I don't see any reasons against that |
87 |
split as long as people are willing to maintain it. |
88 |
|
89 |
|
90 |
cu |
91 |
-- |
92 |
--------------------------------------------------------------------- |
93 |
Enrico Weigelt == metux IT service - http://www.metux.de/ |
94 |
--------------------------------------------------------------------- |
95 |
Please visit the OpenSource QM Taskforce: |
96 |
http://wiki.metux.de/public/OpenSource_QM_Taskforce |
97 |
Patches / Fixes for a lot dozens of packages in dozens of versions: |
98 |
http://patches.metux.de/ |
99 |
--------------------------------------------------------------------- |
100 |
-- |
101 |
gentoo-dev@l.g.o mailing list |