On 07/10/2011 04:37 AM, Thomas Trepl wrote: > 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).
The problem, and this may be specific to Gnome, is that you can't really fix it, you can make it work, but it might actually break the /usr installation (specific examples are provided earlier in the thread). More/better comments tomorrow. > 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. > I'll answer on this to Rob's message tomorrow or Friday, after weighing his suggestion a little more thoroughly. > - 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. Why don't we just remove the idea of "Recommended" all together. A package is either required or it is not -- no gray area. If a dependent package provides known, but non-obvious functionality, put a note explaining that in parenthesis after it (as is currently required for "Recommended" deps -- yes this still leaves a little 'gray' but were not saying "do this or else"). It would require a bit more reading and planning by the end user (and more optional arguments documented by editors/contributors -- no more blind cut and paste for complex packages). -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
