Hi, just my two cents to the upcoming discussion. There are a lot of ideas which all has a valid background. That is keeping /opt or not, splitting the book in parts or not, package management and so on. Personally, i'd like to keep the optoin haveing some packages installed in /opt - but this is a discussion about a technical issues and will become minor weight in context of the books state. I think, the project itself has a problem (if you want to call it a problem, its more a challange) on more organisational topics:
To me it seems that the book suffers on its own perfectness. Taking the Gnome discussion (Wayne and DJ brought in). Even I only once tries to build Gnome and I do not know anything about the troubles they are fighting against, the question is: Why not commiting the stuff which build in /usr well, keeping the instructions in for the /opt. Even the build may fail using a non-/usr prefix, the really important and essential step is done - its shown how to build that specific package. The remainer is that it may not build/work proper when doing it with another prefix - ok, that might be needed to fix, which maybe another one knows how to do it (or simply tries to find out how). When i commited KDE4, i have known that there a lot of bugs in and, surprisingly, they were (and may be still there) some! But what I wanted is to share that stuff and invite everybody else to enhance it, to fix it, to turn it upside down. In this state, its clear that this package isn't ready to be called "ready for release". But i think that is what it must not be - as long as maintainers/editors want it to have in a release of the book. To me, this is a major problem of the book, it doesn't have *releases*. Every package you may want to bring in, is required to be quite perfect as the develoment book is defacto the one and only book were to look in. When I put in a quite buggy package (the BLFS xmls about it, of course), this will have impact on the quality of the BLFS-project at all. It is clear that noone commits bugs by intention, no doubt about this, dont get me wrong here. The intention is to get development done. Looking back to "bleeding edge LFS" times, it was not really bad when development stuff was commited which broke this or that. Time (mostly the team) has fixed that. So, what I like to say is something like: - need more releases The stuff documented in the releases is known to build/work on recent LFSes. When there is no update in the (dev-/rc-)book, it is simply kept as it is. If there comes up an issue with other package versions or incompatibilities with newer LFSes, who cares? Create a ticket in trac and that's it. Someone will pick it up. - maybe a third line: stable, rel-candidate, development I think our BLFS is currently in a permanent release-candidate state. When commiting "my" KDE4, I'd love to have the option to commit it to a development pool. Than, when the team sees that the stuff does well (or complains about bugs gets less), move it to the RC. Sometimes, dunno exactly when, the project leads does releases so the RC gets open again for the development stuff. Maybe it would help to avoid that work is somewhere in the wiki, somewhere in HowTos - that all needs to be in the devel-book. The great work about KDE-4.0(!) slept for years in the wiki. Why not in the devel-book. More people could have an eye on it as they may even recognize that someone has started to work on that package. With this, i'm sure we could have that package in the release- book for years now, not for month as it is currently (and it tends to outdate again, as noone has the heart to throw a new version in). Maybe the branches-idea discussed in this trhead, could address that too. Ah, a last one: Reduce the numer of required/optional depedencies. It is a quite hard work and I'm not sure for what benefit. Yes of course, important depenencies which breaks the build when not fullfilled needs to be documented but recommened/optional --- hmm, it depends so hard on personal tastes what is recommended or optional or required. When an installed package has major infuence on the functionality ok yes, but everything else is written to the configure-log. Someone who is doing BLFS should be able to read that. When i want to authenticate against AD, Kerberos is required for me, for everyone else it may be optional. -- Thomas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
