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. 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 -- 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
