| 1 |
On Thursday 21 October 2004 00:02, andrea ferraris wrote: |
| 2 |
> The first one is simple: in a litle gentoo system that I'm |
| 3 |
> managing for a year now with authomatic nightly updates, |
| 4 |
> I had to update almost manually about a hundred of |
| 5 |
> configuration files. The system (gentoo) is well designed, |
| 6 |
> so, if I didn't update, all works because the original |
| 7 |
> configuration files stay in place, but for the better and |
| 8 |
> also only for the good, the thing to do is to use etc-update |
| 9 |
> to update such configuration files. The problem is that such |
| 10 |
> process is really time consuming and error prone, so it's |
| 11 |
> not very good. |
| 12 |
|
| 13 |
You might want to try dispatch-conf. It is superior to etc-update in many |
| 14 |
aspects, and it comes with gentoolkit. Further there is normally no need |
| 15 |
to update every night. While there is no problem with it, it will |
| 16 |
increase the maintenance load unnecessarilly. |
| 17 |
|
| 18 |
> The second thing is the binary choice. In Gentoo is more |
| 19 |
> difficult than it should be (at least from my point ov view), |
| 20 |
> it is that the system gives the choice of binary updates only, |
| 21 |
> but it's really difficult to find only binary packages and |
| 22 |
> also if one can find them it's impossible to find only |
| 23 |
> modified files in a package and to update only those and also |
| 24 |
> to download only diffs and only binaries diffs. I think that |
| 25 |
> also these things could be achieved studying the Conary |
| 26 |
> way. |
| 27 |
|
| 28 |
The thing is that portage's binary packages are far from perfect when |
| 29 |
compared for example with rpm's. The problem is caused by the fact that |
| 30 |
two seemingly similar binary packages can be different to the extend that |
| 31 |
one will work on your system and the other not. As gentoo is mainly a |
| 32 |
source distribution the effort required to make binaries "better" is |
| 33 |
probably too big. Even then all kinds of binary problems are unavoidable |
| 34 |
and the main cause of releases in all binary distributions, even debian. |
| 35 |
With source one can mix and match, with binary releases one must ensure |
| 36 |
that all dependencies are completely compatible with the versions that |
| 37 |
existed when the package was built. |
| 38 |
|
| 39 |
> Sorry for the length of the message and for the absence |
| 40 |
> of code, practical idea or implementations. |
| 41 |
> I'm sorry, but I can't. |
| 42 |
|
| 43 |
Idea's rule. |
| 44 |
|
| 45 |
On the point of not having a central tree. That is basically a support |
| 46 |
nightmare waiting to happen. In gentoo we have allready problems with |
| 47 |
supporting users that make improper local modifications or use some |
| 48 |
packages from breakmygentoo.net (allthough they seem to have adopted a |
| 49 |
minimum level of quality too). The problem is that as systems get more |
| 50 |
and more dissimilar, problems get harder and harder to reproduce. One can |
| 51 |
also not as a volunteer set up a configuration that is similar to a user |
| 52 |
just for fixing one bug. |
| 53 |
|
| 54 |
As for keeping local changes, that is certainly possible now with gentoo. |
| 55 |
It is fairly easy to set up, allthough not officially supported or |
| 56 |
documented. The concept of overlays is well supported, and probably most |
| 57 |
developers use it for a few of their own packages. Supporting an |
| 58 |
organizational tree is fairly easy too, all required is some hard disk |
| 59 |
space and an rsync server. |
| 60 |
|
| 61 |
Paul |
| 62 |
|
| 63 |
-- |
| 64 |
Paul de Vrieze |
| 65 |
Gentoo Developer |
| 66 |
Mail: pauldv@g.o |
| 67 |
Homepage: http://www.devrieze.net |
Archives