-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello. This is the second in an ongoing series of messages from me as your DPL. This time my topic is porting.
One of the features of our imminent Debian 3.0 (woody) release is that we will support *eleven* different architectures. This is almost twice what we supported for Debian 2.2 (potato) and more than any other Linux distribution. It is, therefore, one very tangible way in which we demonstrate our committment to making Debian a Universal Operating System. In recent times, several commercial Linux distributors have chosen to trim the list of architectures they support. That makes good economic sense for them. Even in Debian, with our plethora of architectures, it appears that around 95% of Package file downloads are for the i386 architecture. Fortunately, Debian can "afford" to support as many architectures as we have interested and motivated developers to maintain... and for woody, that turns out to be eleven! Of course, maintaining software across this many architectures does present challenges. As I mentioned in the question and answer period of our recent election process, one of the most significant things Debian worked through in the last year was a record number of "fails to build from source" or "FTBFS" bugs. A more recent example (that we are working through right now) is how our security team can quickly get a new package version built and uploaded for all of our architectures. A good solution, that involves giving them a high priority path through our autobuilders, is nearly implemented and is the last major hurdle before woody releases. The big advantage we gain from all this porting work is that the quality of our packages improves. Many of the problems our porting teams address result from ambiguities and laziness in coding. In other words, there are things that work fine on some architectures but break hard on others, and things that the toolchain happens to let work today but might break in the future. Solving these problems in the process of porting may well prevent us from having programs unexpectedly break on popular architectutres in the future when elements of our toolchain are updated. Porting also prepares our packages for the future in more direct ways. To make Debian run on the hppa architecture, for example, porters have already investigated and addressed an immense number of package building problems that result from the changes made between GCC 2.95 and 3.0. Very few of the C++ programs packaged for Debian compiled using g++-3.0 the first time. If the hppa porting team hadn't already motivated us to discover and resolve most of these problems, we would be facing a potentially much tougher job after woody to move Debian to gcc 3.X as our default toolchain. And it isn't just Debian that benefits from all this work! Most of the patches developed to port Debian packages make it to upstream authors for broader release into the community at large in future versions. So, what does the future hold for our architecture list? First, we may well have an additional architecture or two in our next release. The AMD "Hammer" family, and the Hitachi SH family, may join our list of released architectures. We also have active groups working on alternate kernel environments, such as the Hurd and various flavors of BSD, that will eventually push us to generalize our thinking about what an "architecture" means in Debian. There is also a limitation of our current packaging toolset and related policies that we need to address before our next release... We already have several architectures that really want to support multiple binary package architectures on the same system. Examples include ia32 user programs on ia64, and 64-bit userspace support for hppa, sparc, etc. This starts with the ability to easily install packages from more than one Debian architecture on a system, which quickly leads to filesystem layout and related issues so that the same shared libraries can be installed for multiple architectures at once. Getting this to all work right without making a mess of our packaging system, or running afoul of the many traditional expections placed on Unix-like systems, won't be easy... but we must do the work! I hope this helps explain for at least some of you why I think it's valuable for Debian to support so many architectures. As an active member of Debian's porting community, I have been gratified in recent months to see so much support from all of you who have received and dealt with "FTBFS" bugs against your packages. Keep up the good work! I know it's harder to get things to build cleanly on eleven architectures than one or two, but the results make the effort well worth it! Thank you for your time. Bdale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 <http://mailcrypt.sourceforge.net/> iD8DBQE857TcZKfAp/LPAagRAg5UAJ9LHgdBcJEMFIXjU+bamt46fBWseQCghusU e85EHH1A3e62PGEmEMu7lKc= =ellS -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
