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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
