X packages

pcpa at mandriva.com.br pcpa at mandriva.com.br
Thu Dec 6 17:14:33 PST 2007


  Hi,

  Just cc-ing x-packagers as the list has very low traffic, and maybe not
all "x packagers" are subscribed.

  In this email I will attempt to explain a "way of packaging X" for
Mandriva Linux, that I have almost finished implementing; and hopefully
help others, or get some feedback about possible mistakes I am doing,
or even better, get some consensus about some problems that may be
common to all distros regardless of operating system.

  All distros have some custom changes, or changes that are not considered
upstream ready because it is a work in progress, or possibly some extra
value added to the specific distro, or some operating system specific
feature interface.

  For Mandriva, I am mirroring most of anongit.freedesktop.org. And I
am working on these branches, that I update based on server-1.4-branch,
and later may adjust for other "stable" branch:
* mandriva         Has changes that are considered "upstream quality" and
                   hopefully will be added to upstream some day. And is
                   expected to br easy for upstream commiters to pull code
                   from this brach.
* mandriva+custom  Not really "upstream ready" or qualified. In the case
                   of this specific branch, it has things like a "blue
                   background" instead of the default "stippled"
                   background, etc, and one patch that I am not
                   "fully happy" with it yet, that handles keyboard
                   events using SIGIO and allows killing an application
                   or the X Server when Ctrl+Alt+Backspace is pressed.
                   It kills the client if handling a client request, or
                   the X Server if not handling a client request. This
                   doesn't prevent all types of crashes, and if some code
                   blocks SIGIO before entering an infinite loop, it does
                   nothing...
* mandriva+gpl     This probably will not enter upstream. Currently it
                   has some Debian patches/customizations and Xvnc code.
                   It also has some Mandriva specific GPL code, and new
                   code, that doesn't touch existing files, that I am
                   implementing is also going only to this branch. Any
                   gpl code can only enter this branch, at least until
                   mainstream accepts GPL code. This is also the branch
                   that will be used for Mandriva packages.

  Since Mandriva uses rpm, and I am mirroring "upstream" I also use
git-archive to generate a tar dist file; this may require something like
autoreconf before ./configure, but the patches already require it to
regenerate some ".in" files, therefore there is no reason to store files
not in the repository in the tar file, this also reduces some Mb in the
tar file, and git-format-patch to generate the patches, and maybe some
``git-magic'' for more "pleasant" patches that address a single
problem/fix at a time, and doesn't require a specific branch for it.

Things that are "work in progress":
  I am considering to add a tag in the repository for every new package,
but unless I automatize it, this may not be implemented.
  One of my patches, that is in the "main" mandriva branch (and also present
in mandriva+custom and mandriva+gpl) is a change to compile most code with
-fvisiblity=hidden. I have it already working, but I did most of it in a
"hard" way, analyzing missing symbols, following macro definitions for
symbols that are defined by macros, fixing/rewriting things like
"#define foo_func ((type (*)(foo_args)) LoaderSymbol("foo_func"))",
"ansifition" of some files (they already have ANSI declarations), and
fixing a few problems like a C file with a statement like
"extern type some_func(some_args);" but the "some_func" function doesn't
exist anymore, so I am putting declarations in header files, etc.
  Today I wrote a perl script that will use "objdump -t -T -w" for every
library/module, and use ldd to "augment" the list of available symbols on
the shared objects. After parsing the output of objdump, the script
knows where symbols are defined, the type of the symbol and where it is
required, as well as warn if an symbol is "hidden" in one shared object
but required by another, a "minor" warning if a symbol is exported but not
used by any modules, and a warning about symbol clashes, a example is stub
symbols in libXfont that the X Server implements another version of the
symbol; if this symbol is made hidden, things will crash badly as the stub
in libXfont will be used.

  One thing that I still did not stop to start writing code is inter module
dependency. At first I considered using something like the makedepend
program from monolithic X Server build, or figure a way to create a "sign"
for every symbol, and cross-reference it to know if a module needs to be
rebuilt. Maybe GNU "autotools" already have something similar to makedepend
that I am missing. I don't want to make a new release of every module
because someone added an ErrorF in the X Server code or some library,
but I want an easy "automatable" method of detecting when a module needs
to be rebuilt, due to some change in some structure, function return type
or arguments, etc. If someone already have something to resolve this
problem, that is a side effect of converting the "monolithic" X Server
in a huge amount of different packages, I would like to know :-) Otherwise
I am also considering to analyze how the Linux kernel handles dependencies,
and symbol "signatures" and try to implement something similar.

Thanks,
Paulo






More information about the xorg mailing list