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


Reply via email to