X-Git-Url: http://git.linux-vserver.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=util-vserver%2FREADME;h=7e6caf1e6c7408dbda030082b8b170c9c753878e;hb=9c2cb19d6aee1ff6638c442894f22bb747477582;hp=702b798776d6f2ca3bdaf7e9abdb833031dd38a4;hpb=38549ce7d8fd2c8e07b04227bb03422ba15bd48c;p=util-vserver.git diff --git a/util-vserver/README b/util-vserver/README index 702b798..7e6caf1 100644 --- a/util-vserver/README +++ b/util-vserver/README @@ -39,14 +39,17 @@ Red Hat 7.3, Red Hat 9, Fedora Core 1&2 for path-detection only and paths from RH systems will be assumed by default, this should not be a big problem. -* guest systems can be created with the 'apt-rpm' build-method. This - requires the 'apt' package e.g. from http://fedora.us. Before first - invocation, a near mirror should be activated in +* guest systems can be created with the 'apt-rpm' or 'yum' build-methods. + The first one requires the 'apt' package e.g. from http://fedora.us and + the configuration of a near mirror in | /etc/vservers/.distributions//apt/sources.list (To avoid slashdotting by the masses of util-vserver-users, there - does not exist a standard mirror) + does not exist a standard mirror). + + The 'yum' method uses the repository configuration shipped by the + fedora-release package. * RH/FC uses the 'sysv' initstyle which is assumed by default @@ -59,8 +62,8 @@ Red Hat 7.3, Red Hat 9, Fedora Core 1&2 * when having RH/FC guestsystems, it is *strongly* recommended to use a dietlibc linked version of 'rpm-fake-resolver'. Else, package - installation with 'vrpm' or 'vapt-get' can fail since users can not - be resolved. + installation with 'vrpm', 'vapt-get' or 'vyum' can fail since users + can not be resolved. @@ -151,14 +154,18 @@ a level of the featureset stability but not of the software stability. E.g. 'stable' is not really stable: it has huge security problems and missing functionality. But you can expect that the current configuration -will work in future versions also. +will work in future versions also. This version is untested on author's +side and it will be hard to bring patches/fixes in, since it must be +proofed that they will not break anything. In the opposite, the 'alpha' branch does not have known security issues -and works well on author's system. But it may happen that some behavior -or configuration options change. With 'alpha' you should be still able -to use vservers created with the 'stable' branch, but you may encounter -some oddities -- especially on kernel 2.6 systems (e.g. 'vserver-stat' -will show the names of old vservers). +and works well (at least on author's system ;)). But it may happen +that some behavior or configuration options change. + +With 'alpha' you should be still able to use vservers created with the +'stable' branch, but you may encounter some oddities -- especially on +kernel 2.6 systems (e.g. 'vserver-stat' will not show the names of old +vservers). So let me summarize: