On 12/23/2010 12:45 PM, Richard W.M. Jones wrote:
On Thu, Dec 23, 2010 at 11:49:48AM -0500, David Ward wrote:
> I am writing to learn more about the plans for developing febootstrap 3.x.
>
> I am not questioning the value of building supermin appliances, but I am extremely
concerned about the chroot-creation functionality being removed entirely from febootstrap
3.x without any viable replacement for it (please correct me if I am overlooking
something). This effectively removes the ability to create diskless NFS clients,
following the rough process outlined at
http://fedoraproject.org/wiki/StatelessLinux/CreateClientImage (using febootstrap in place
of anaconda which no longer supports the --rootPath option). Even if the code is not
perfect yet, I would like to see the existing functionality remain in Fedora 15 and
beyond.
OK, first time I found out that people were using it like this. I would suggest forking
febootstrap at 2.11. We already have a branch for that here:
http://git.annexia.org/?p=febootstrap.git;a=shortlog;h=refs/heads/feboots...
Call it something like 'febootstrap2' and the two should be able to co-exist.
We (ie. libguestfs) have only been using febootstrap to build supermin appliances for a
very long time. Sure, we built an appliance, but then we threw it away and just used the
supermin appliance :-) The new way of doing it, where we don't build an appliance and
throw it away, therefore makes a great deal more sense for us.
> I think it would be much better to take the supermin-appliance-building code and
package it into something new (call it "supermin"?), and allow febootstrap to
co-exist in its pre-3.x form and receive updates. (I actually have some fixes I would
like to contribute to pre-3.x febootstrap.) The name "febootstrap" implies a
Fedora variant of "debootstrap", and I just see this creating all kinds of
confusion.
I take your point, but either way someone's going to have to get a new package into
Fedora, get it reviewed, maintain it etc. and I'd rather that person wasn't me,
since the 2.x code isn't of any use to me, and
maintaining fakeroot/fakechroot was always a very difficult area.
Rich.
Rich,
I admit that I have not been involved with Fedora beyond submitting a
few patches for some existing packages. However based on my
understanding of the Fedora project, I'm not following the rationale
here, so please help me understand.
A brand new application (dubbed "febootstrap 3.x") was written entirely
from scratch, in a different language from febootstrap (OCaml vs. bash),
that does something quite different from febootstrap (it builds supermin
appliances instead of chroots). I think this would suggest that
"febootstrap 3.x" should have to undergo the normal review process for a
new Fedora package. But instead, the existing "febootstrap" package
which was already accepted into Fedora is basically being replaced with
unreviewed code, which has removed the chroot-building functionality out
of Fedora without any packaged alternative (again, please correct me if
I am wrong). The chroot-building functionality is necessary to perform
diskless booting from NFS, which is a goal of the Stateless Linux
project:
http://citethisbook.net/Red_Hat_Introduction_to_Stateless_Linux.html
If you are looking for a new maintainer for febootstrap, I think that is
one thing, but I would urge you not to actively remove functionality
from Fedora that is currently being used without providing an
alternative for it.
I particularly disagree with the notion of calling the chroot-building
code "febootstrap2". This implies that the supermin-building code
supersedes the chroot-building code, which it does not. I think there
is value in both capabilities and they should both continue to be
developed further and packaged natively in Fedora. I repeat my earlier
concern that the name "febootstrap" suggests "debootstrap for Fedora",
which febootstrap 2.x is, but "febootstrap 3.x" is definitely not. I
think the supermin-building code needs to be called something else and
packaged in such a way that it does not interfering with febootstrap.
I am curious if there are other febootstrap users who share my concerns,
and what thoughts Fedora QA has concerning this?
Thanks,
David