On 30/07/11 21:20, Thomas Trepl wrote: > On Saturday 30 July 2011 02:29:55 Randy McMurchy wrote: >> ... >> I was hoping that my response to your post would encourage additional >> responses. Actually, I am surprised that it has not. All that has >> happened is additional packages have been added to the book which is >> the opposite of where you suggest we go. I am wide open. Let everyone's >> opinions flow! >> >> I am open to suggestions, let the community speak out! C'mon, we need >> to keep BLFS alive! > > Oh yes, the topic should cause an agile discussion. I think to come up with > valuable suggestions is nearly as hard as keeping BLFS up to date ;-) > However, > some interesting ideas, opinions and suggestions did came up and to me - > speaking for myself - it looks like the following: > > I hardly think that BLFS reaches a level of complex which is not longer > maintainable but in my eyes, the quality standard has grown that high, that > it > makes a simple version upgrade or add a new package to a remarkable time > consuming task. Maybe we cut that a bit - for example, the depenencies of > packages is where we should do a review. As I said in another post, it isnt > quite clear when is what required, recommended or optional. I thought i mentioned my opinion on this quite some time ago, but here it is again? I think we should keep the recommend dependency. Recommend should be a dependency that is no required to build the package successfully but requires a disable parameter if it is not installed otherwise it fails. Optional should be a dependency that is no required to build the package successfully and does not require a disable parameter if it is not installed for a successful build. This is a black and white rule that should not have any ambiguity. Anyone have any objection by this definition?
A package needed > because the other package will not compile if it is missing - this package is > of course required. But the difference between 'recommended' and 'optional' > is > not clear (to me) and maybe can merged in one section. > > Another thing where I'm thinking about is the topic 'Release'. To me there > are > only two options: > > Either do releases, which will result in some kind of "stable book"s which > can be seen as something that really works fine, but maybe does not use the > most recent versions. The development branch will be freed from the trammel > of > 'it all must work with eachother'. This is the devel-branch and bugs, errors > and incompatibilities are allowed to happen. As I'll say later again, that > may > speedup development and makes it easier to have new versions in the book. But > the challenge will be to come to a state wher a stable release could be cut > off. This is what I was trying to convey, having multiple branches where things aren't so perfect. > > Or, the other option, if we will not cut releases, then drop the stable > book > as it is a (3 years old) *release*. Than rename "Development BLFS" into > simply > "Beyond LFS book" or so. But when doing so, we also need to drop the demand > on > 'everything works perfect with each other'. Than I think, it will not be > possible to check all the time if pkgconfig will still work when upgrading > glib2 from 2.24.2 to 2.24.3 (ok ok, I know, thats a dumb example). But what I > want to say is that we should go a bit more in the direction to assume that > other pkgs will still work if upgrading. If not, someone will recognize and > report that and then this could be fixed. For the most part that would work, but as an example, if you upgraded glib2 which broke Gnome, then the only option would be to upgrade Gnome's 50+ packages which would take ages to do so. We might end up in a never ending cycle of catch up. That is why I say something like Gnome should have a separate development branch. A separate branch is just like having a separate book but with some benefits. Working on such a ticket is a team > issue where it can be discussed how to fix, do this, do that. If you want > upgrade a pkg, currently you are more or less alone to find and fix > incompatibilities (before you commit an upgrade). Maybe relaxing here could > help to speedup in the race with new package versions. Thats a different > approach as we must tell the people that we do our best to keep everything > working, but when it does not, ok, we have warned you that this could happen > but will try to fixed that. > > You see, I like the 'bleeding edge' thinking - everything is quite uptodate, > but because of that, it may not work proper. So be it ;-) But what IMHO > will > not work is to live at the bleeding edge AND keep it stable. > > I still didn't come to a decision on whether I like or not the idea of > splitting the book in more (more or less independent) parts. But I feel thats > an idea which is worth to think about. What I would not like so much is to > transform the book into a wiki. I believe that there will be too much efforts > to keep it structured which is automatically done using the docbook. Learning > the latter is not that hard. > That does not address Fenna's idea of doing a full restart and keep what we > have in a wiki (or whatever). The idea of doing a restart from scratch is > cool > as it may offer the option to modify the docbook stuff for whatever > improvements instead of need to update hundrets of XMLs. Another effect could > be that we could see, where people are really interested in. > > Just another 2 cents, > > -- > Thomas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
