More about x-packages

[pcpa at mandriva.com.br]

  Hi,

  I posted to @x-packagers and @xorg some tim ago about a "buildsystem"
for x packages, and a way to possibly use git to simplify package
management.
  Besides I still don't have it fully finished, did not receive any
feedback other than local (at Mandriva) feedback *when* I finally started
implmenting it, I will try to describe it again, but first, I will point
some problems that I noticed, that may be of interest of packagers, but
I still don't have a formal description of all problems, because I still
did not finish the sytem.

  Problems that may be of interest of "x-packagers" (if your package
already have patches for the problems, please disconsider):

(Also, to add a point, I did not work with "X Packages" for quite
some years, so forgive me if I am being stupid or something :-)

  With "default" build at X Server 1.3 time (i.e. most distros out there):
  There are several broken modules, due to things like ramdac symbols not
available, what breaks several video drivers (fixed in 1.4).
  There are some modules that have undefined functions, that when
inspecting the sources, I found out that they are actually macros :-o
that were compiled as missing functions (fixed in 1.4).
  I think a lot of distros shipped sun/sparc video modules, just because
they compile in x86, and/or made default installs for hardware that
"should" work on x86, but is usually used on other platforms.
  libxf4bpp.so has a lot of missing symbols, so it is unlikely the vga
driver for example, will work, libxf1bpp.so has basically the same missing
symbols, but this is fixed in 1.4.

  With current 1.4 branch:
  A large amount of input drivers are broken, and I posted some more
details on another email, this is basically due to symbols no longer
available on the X Server.
  The i2c builtin module is really ugly with those macros in the format:
#define I2C_WriteRead      ((Bool (*)(I2CDevPtr, I2CByte *, int, I2CByte *,
int))LoaderSymbol("xf86I2CWriteRead"))
  Someone can post more details if this is broken or not, but a huge
amount of symbols with the same name are available in libcfb.so and
libmfb.so, but probably it is ok, unless there is some case both can
be loaded (and I think there is no such case).
  There are a few instances of C source code with things like:
extern some function(some args);
and calls to the function, that doesn't exist anymore. I am writing this
email from memory, I remember now only about the savage driver,
savage_vbe.c call to vbeModeInit, the others I patched locally when
finding them).
  At least libxf8_32bpp.so is currently broken, due to unresolved symbols,
but those are also "ugly" files with lots of symbols generated by macros,
and reincluding source files with different macro definitions.


  Now, about the system I am working on:
  I am using a git mirror of freedesktop, where I use 3 main branches, and
modules also have branches with the same name.
mandriva         Code that should be ok to add to mainstream
mandriva+custom  Work in progress patches, or things that are not
                 considered mainstream quality, but fix some issue
                 in the distro
mandriva+gpl     The distinction is due to the fact that GPL code currently
                 isn't accepted in main Xorg, and branch created to allow
                 easier integration of such patches/mods, and still keep
                 the repository in a format that allows easy pulling
                 for other people that want to make sure only a permissive
                 license is used.
  Currently, I am experimenting with git-archive to generate a tarball,
and git-format-patch to generate the patches. The benefit is that it can
be automatized, and there is no need to store huge binary files, and only
files under version control enter the tarball. The bad side is that it is
something new, and you can find people that dislike it. I generate
tarball/patches to submit to a ``standard rpm build system''.

  I also done a set of macros, so most configure.ac's and Makefile.am's
of modules can be simplifield, instead of everyone having something like
a cut&paste of the same code to check for --disable-dri, --enable-exa,
and the like.
  Actually, there is a problem with --disable-dri, that XF86DRI is
actually defined in xorg-server.h, so if the X Server was compiled with
dri enabled, there isn't a standard way to "force" a module to compile
without dri support, but fixing this detail is in the aesthetic/logic
side.
  I hope to analize the output of the compilation of all modules, as I
am compiling all of the them with lots of warnings enabled, that hopefully
can catch other problems.
  Also, I have basically finished a build where almost everything (but
mesa and libraries) is compiled with -fvisibility=hidden, and symbols
used by different modules are properly "exported" using _X_EXPORT. I also
wish to possibily post more information about it soon, but most of the data
is collected by a perl script that analyzes the output of objdump and cross
references the data so that, while it doesn't point out about symbols that
should be exported (but then, there isn't really a well defined API for
developing modules/drivers), it will detect missing symbols, symbol clashes,
warn about symbols that are hidden but required by some module, etc.

Thanks,
Paulo