1 |
On 1/2/07, Alan McKinnon <alan@××××××××××××××××.za> wrote: |
2 |
> |
3 |
> On Monday 01 January 2007 04:34, Mike Myers wrote: |
4 |
> > The update system is the -only- nice thing about it over Gentoo. |
5 |
> > Debian is nowhere near Gentoo when it comes to everything else |
6 |
> > (especially docs). I don't think suggesting a single feature that |
7 |
> > another distro has and putting into Gentoo is trying to make it a |
8 |
> > clone. I'm just asking for a relief from having to constantly worry |
9 |
> > if updating something out of the 300 packages that need updated is |
10 |
> > going to break something, and not having to make sure etc-update |
11 |
> > isn't going to destroy my custom configs afterwards. If it wasn't |
12 |
> > for that, Gentoo would be perfect. I'm sure there's got to be others |
13 |
> > that would agree. |
14 |
> |
15 |
> At this point it might be helpful to revisit what gentoo really *is* in |
16 |
> engineering terms |
17 |
> |
18 |
> Gentoo is not an off-the-shelf, commodity, we-do-everything-for-you and |
19 |
> you don't have to think (much) distro, it's in a completely different |
20 |
> class. The devs have given up the ability to configure things a certain |
21 |
> way and handed that control over to you. You get increased |
22 |
> customizability but have to pay the price of increased knowledge and |
23 |
> responsibility, including that you get to keep both pieces when you |
24 |
> break it. |
25 |
|
26 |
|
27 |
|
28 |
What I was suggesting wouldn't take away from that at all. |
29 |
|
30 |
Red Hat and Ubuntu can do all these tests for you, the gentoo devs can't |
31 |
> (except in some very broad cases like package-1.0 is config-file |
32 |
> incompatible with package-2.x), so we gentoo-users have to do these |
33 |
> tests ourselves. |
34 |
|
35 |
|
36 |
I don't completely disagree. But, I would just like to at least be aware |
37 |
that I am testing something and that I can half expect it to break. Like, |
38 |
then otherwise what's the point of using ~x86 if x86 is still testing? If |
39 |
I'm using x86, I don't see why it's so wrong, (or against the Gentoo |
40 |
philosophy as it seems to be) to expect a reasonably stable system |
41 |
(obviously not perfectly stable). |
42 |
|
43 |
Remember the old joke: "We can make it cheaply, quickly, correctly. Pick |
44 |
> any two." You have a case like this, maybe it's time to just get over |
45 |
> it :-) |
46 |
|
47 |
|
48 |
I'll have to remember that one :P |
49 |
|
50 |
alan |
51 |
> |
52 |
> |
53 |
> -- |
54 |
> gentoo-user@g.o mailing list |
55 |
> |
56 |
> |
57 |
|
58 |
Gentoo has release cycles anyway, like 2006.0, 2006.1, etc. So why is it so |
59 |
much to ask to use those profiles to actually be used to deal with updates? |
60 |
It's apparently being discussed by the devs anyway. Although, when I ask |
61 |
about such a feature I feel as though I'm somehow threatening the Gentoo |
62 |
community or philosophy with some kind of ticking time bomb or something. |
63 |
It's not like adding one feature towards stability is going to cause people |
64 |
to confuse Gentoo with Red Hat or something just totally insane and left |
65 |
field. I'd rather see something like this though than something like random |
66 |
ebuilds being redesigned somehow and breaking randomly because something was |
67 |
slotted out of the blue, or went modular and now has to build 600 packages. |
68 |
I guess my main concern is simply the randomness of the portage tree. If |
69 |
'tree versions' were actually implemented, like what is/was being discussed, |
70 |
then that issue would dissolve. This would also give users more options, |
71 |
which from what I understand is the Gentoo philosophy. They could have a |
72 |
'testing' tree where it's up to date as possible like the current method, or |
73 |
they could use a released tree. Where the packages in that tree suffer no |
74 |
major changes (like going modular or virtual) or go from one branch (or |
75 |
"slot") to another with an emerge -u* world. |