On 06/23/2012 12:46 AM, Fernando de Oliveira wrote: > Em 20-06-2012 02:44, DJ Lucas escreveu: > [...] > >> I'm not sure about once per month, but it should happen >> periodically...but I'm going to take it a bit further (see below). If we >> stick with the format in the book now, I'd suggest the usual security, >> feature, and bugfix updates as they always have been done (when an >> editor (usually me) deems it necessary), in addition to a scheduled >> quarterly update. This would give us ~6-8 scheduled releases between >> katamari releases, but, on to the new subject line... >> >> Unlike other packages in BLFS, I've unintentionally limited Xorg updates >> over the past several years to release updates (katamari), security >> updates (few), and the occasional feature group updates (as above) due >> to the incrementing release number that is tacked on to the wget lists. >> This is usually when somebody chimes in with the "separate the packages" >> argument, and where I shoot it down citing the amount of work it would >> take and the user experience. I always give the thumbs up for >> educational and packaging value, but down it goes when it comes to a >> user's experience as we go from something like 35 sets of instructions, >> to around 270 sets of instructions from start to finish (not to mention >> the editor workload involved). >> >> Well, I'm not going to shoot it down tonight, but rather suggest a >> compromise, one that I've hinted at before. What I envision for that >> compromise is that we continue with the logical groups of packages on >> one page (I really do like the additional drivers page that was added, >> but it could be simplified even more for the group of packages pages), >> with instructions to create the wget and md5sums lists with the cat > >> file << "EOF" syntax, instructions to edit those files based on the >> information below (package information and purpose), and the completed >> loop instructions on the page. This makes individual package updates >> easier as we are not assigning an arbitrary build number which requires >> new wget and md5 file lists to be generated, each package's purpose (or >> lack thereof) can be explained, and we cater to the packagers without >> giving up our simplified build of ~35 sets of instructions (which will >> continue to be necessary for the average user). >> >> With the above goals stated, if we are going to do it, then it needs to >> be done right the first time. We can stick with what we have now and >> take our time to attack the interdependent explanations of the packages. >> I plan to do a -2 release about a month after Meas/libdrm is completed >> to give the upstream packagers time to incorporate the changes in their >> respective packages after general availability. I'm open to suggestions >> on the explanations here, but I suspect it will come in a totally >> foreign dependency order (actually reversed for the most part) due to >> the way that Xorg was separated (Ex: This package contains protocol >> headers for libXabc, libXxyz, and the server components X, Y, and Z.). >> Comments or suggestions would really be appreciated here. The pages >> could be written initially without the package descriptions/explanations >> to get most of the grunt work done by whoever might be interested in >> helping. >> >> Have any of you already started on documenting any of this on the side? >> Is there a dependency matrix someplace that I'm unaware of? I'll plan to >> do a quick mockup of the proto page (hopefully this weekend, following >> any info gleaned in this thread) as an example and a template of sorts, >> but I definitely need volunteers. I assure you that if left to do it >> alone, you can expect completion sometime well after the end of the >> world in December! ;-) >> >> -- DJ Lucas >> >>
Yuck! I don't believe that world will end in December. > > I like the idea. So, an individual package being upgraded, the cat .. > EOF. sounds good, easier for book upgrade patches, if I understand > correctly. I am looking forward to see the proto page. > Great. I've said that I'm going to split Drivers into individual packages in Python/Perl Modules or Additional Xorg Drivers style (All of them on one page, but still seperated - since not all of them are really needed for one machine). Looking at this thread, I could also make instructions for generating wget and md5sum lists at the beginning of the instructions. I plan to start that in the first week of July since I have some exams to do right now and I don't have any time for that. > I am willing to volunteer to what you think I could do. > > If I take a page from xml, make changes and post a diff this is what you > would need? > > Cheers, > Yeah, just clone the repo, edit xml and post "svn diff" output as an email attachment. Check if it validates before sending it. Someone will look at your changes and possibly merge them if they seem apropriate. See http://www.linuxfromscratch.org/blfs/edguide/ for some basic information regarding book editing. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
