Bits from the DPL
-----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 debian-devel-announce-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: