febootstrap 3.x Plans

[David Ward]

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/febootstrap-2.x
>
> 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