DJ Lucas wrote: > On 06/19/2012 08:18 PM, Fernando de Oliveira wrote: >> Since we had a discussion about upgrading Xorg, I stopped doing some >> upgrades. Other than the few new splits, I only had to upgrade 8 packages: >> >> -libX11-1.4.99.901.tar.bz2 +libX11-1.5.0.tar.bz2 >> -libXaw-1.0.10.tar.bz2 +libXaw-1.0.11.tar.bz2 >> -libXft-2.3.0.tar.bz2 +libXft-2.3.1.tar.bz2 >> -libXi-1.6.0.tar.bz2 +libXi-1.6.1.tar.bz2 >> -xbitmaps-1.1.0.tar.bz2 +xbitmaps-1.1.1.tar.bz2 >> -xinput-1.5.99.1.tar.bz2 +xinput-1.6.0.tar.bz2 >> -xmodmap-1.0.6.tar.bz2 +xmodmap-1.0.7.tar.bz2 >> -xorg-server-1.12.1 +xorg-server-1.12.2 >> >> With much respect, IMHO, as Xorg is not anymore monolithic, i.e., is >> modular, it would be good keeping doing upgrades, for example, once a >> month, as several distros do upgrades continuously. >> > 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.
Embedding the md5 and wget files in the book seems like an OK idea to me. The only caveat is to consider the release plan. Right now, I'd like to release a coordinated LFS/BLFS on 1 September. That means a package freeze and an -rc1 for both about 1 August or slightly over one month from now. Would such a change be reasonable by then? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
