sane dependencies -- a positive look at 'fix your packages'

Andy Hanton andyhanton at comcast.net
Sat Oct 4 07:25:09 UTC 2003


I think that the 'Kind request: fix your packages' thread is going off
course by discussing how to fix what we have instead of what we need to
implement to make Sean's vision possible while making it possible to
support older systems easily.  

I think that we need development tools that work more like the tools on
Mac OS classic.  Macs didn't actually have libraries so they got some
very cool features for free.  You can actually build an application on
Mac OS 9 and run it on Mac OS 1.  You don't need a chroot environment or
any other fancy setup.  All you need to do is stick to the API that Mac
OS 1.0 supported and it just works.  The bad part was that if you used a
function that wasn't supported the application would crash at runtime. 
Because Linux has library versioning it should be able to get the
flexibility of compiling easily for older systems while knowing for sure
that the binary will work on the old systems.  

On Linux the dependencies of a library or binary get inflated by the
system.  For example all binaries built on Redhat 9 depend on libc 2.3
but they usually don't depend on any new APIs introduced in 2.3.  If
each developer compiled against the minimal library versions necessary
then the resulting binaries would be nearly universal when used with an
rpm repository. For example it would be possible to compile abiword 2.0
with gnome support on RedHat 9 or Fedora 1.0 and have the same binary
run on redhat 7.3.  The package manager would automatically the gnome2
platform libraries from the Fedora 1.0 release and install them. 
Although it would require more disk space, end users would probably
prefer to have only one Linux/i386 binary just like there is only one
Windows binary.  

I am not a compiler guru, so I don't know how we get there.  It might be
a good idea to compile the core of the OS inside a LSB chroot.  Another
possibility might be using pkg-config to request a specific minor
version of a library.  It might look something like gcc -o foo foo.c
`pkg-config --cflags --libs gtk+-2.0:2.0 libgnome-2.0:2.0 libc-2:2.2`

The library would implement this by specifying a preprocessor macro to
set with the requested library version number.  Then it would add ifdefs
to the headers so that only the symbols available in the particular
version would be available.  It would be cool to support aliases for
different versions.  For example gtk+-2.0:LSB_2_0 might be equivalent to
gtk+-2.0:2.0.  

There might be some extra linker magic necessary, but since RedHat
employs lots of compiler tool chain experts I don't think it would be
impossible.  It might be possible to reuse whatever tools the LSB
project is using to generate stub libraries for each minor version of
every library.  

To make the automatic dependency fetching work right the repository
should probably provide a mapping between library names and package
names.  I would think that it would be easy to write a script that would
extract this information from all the rpms in a yum or apt-get
repository and write it to a file with a standardized name and
location.  

In this setup a few programs that can optionally use a feature that a
newer distribution has would need to be compiled more than once. 
Packagers wouldn't need to figure out the dependency information because
the developer would have already done that work.  Unfortunately, if a
single  binaries could be built to run on any recent Linux system, then
the author of the code would probably package the binary themselves. 
Some Fedora developers would need to find a new way to spend their free
time.  ;-)

-- 
Andy Hanton <andyhanton at comcast.net>





More information about the fedora-devel-list mailing list