1 |
On Sun, 31 Dec 2006, Mike Myers wrote: |
2 |
|
3 |
> On 12/31/06, Mark Kirkwood <markir@××××××××××××.nz> wrote:Mike Myers wrote: |
4 |
> > > I just wanted to add something to the original post. |
5 |
> > > |
6 |
> > > I've recently began experimenting with Debian and noticed their updating |
7 |
> > > system is exactly like what I was asking about. Basically, there's |
8 |
> > > package updates, and then there's distro updates. Why is it |
9 |
> > > unreasonable for Gentoo to have something like this? I think it would |
10 |
> > > help Gentoo a lot in the server market, where scalability is important. |
11 |
> > |
12 |
> > While this is true, one of the differentiating points of Gentoo is |
13 |
> > precisely the build-from-source idea (there are plenty of binary update |
14 |
> > distros out there). |
15 |
> |
16 |
> |
17 |
> I'm not trying to suggest that Gentoo should go to a binary distro or |
18 |
> anything like that. Besides, it's easy enough to just use a binary package |
19 |
> server if that's what one needs. I'm just wondering why there isn't some |
20 |
> kind of update management system to like, differentiate minor updates like |
21 |
> firefox 1.5.0.5 to firefox 1.5.0.7 and major ones like, y'know, gcc 3.4.4 to |
22 |
> 4+? The way it is now, they're all lumped together like one big update. |
23 |
> The lack of such a system might make it easier for the devs.. but this is a |
24 |
> pain in the ass for the users when they run into a problem like this |
25 |
> unexpectedly. It's even worse when that user is managing several Gentoo |
26 |
> machines. This kind of thing does not scale at all. |
27 |
|
28 |
The problem is that the chance of something breaking gets higher the more |
29 |
you do at once, and the chance of something you need to be able to recover |
30 |
also breaking goes up sharply. I've been watching people use Debian for |
31 |
quite a while now, and I've rarely if ever seen a system upgrade without |
32 |
major problems. People have problems like: the new release has a version |
33 |
of Apache that has a different config file arrangement, and it's hard to |
34 |
make a new config file that handles the web app the system is supposed to |
35 |
be running; the old Apache worked fine, but the new release doesn't use |
36 |
it, and the old binary requires a ton of libraries that the new release |
37 |
doesn't have, either. And there's no easy way to downgrade to the old |
38 |
release until you have time to mess with config files. |
39 |
|
40 |
With Gentoo, you find that the new apache doesn't work with your config |
41 |
files, so you mask it until you have time to deal with it. |
42 |
|
43 |
> I'm just asking for a relief from having to constantly worry if updating |
44 |
> something out of the 300 packages that need updated is going to break |
45 |
> something, and not having to make sure etc-update isn't going to destroy |
46 |
> my custom configs afterwards. If it wasn't for that, Gentoo would be |
47 |
> perfect. I'm sure there's got to be others that would agree. |
48 |
|
49 |
Well, there are two goals here: make it so you can do all the safe updates |
50 |
without any of the ones which will require manual fixing, and make it so |
51 |
your custom configs are protected. |
52 |
|
53 |
I think it would be useful to have an ebuild thing for "upgrading to this |
54 |
package from version {expression} requires the following steps", such that |
55 |
the message will be displayed only if you're doing that, and such that the |
56 |
upgrade will be masked if you're being conservative in upgrading. |
57 |
|
58 |
I also think that emerge should keep track of the config files installed |
59 |
by packages, so that etc-update knows if you've got local modifications, |
60 |
and give you a big warning when you might lose a change you made. |
61 |
|
62 |
-Daniel |
63 |
*This .sig left intentionally blank* |
64 |
-- |
65 |
gentoo-user@g.o mailing list |