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 > >
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. 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, -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
