adjusted the vc_net_nx_type enum so that the NETTYPE_USER2KERNEL() can
[util-vserver.git] / util-vserver / README
index 702b798..7e6caf1 100644 (file)
@@ -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/<id>/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: