Proposal on how to handle xorg include patches (WAS: Re: X Strike Force XOrg SVN commit: r28 - /)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
X Strike Force SVN Repository Admin wrote:
| +|
| +|--> xorg-source-include --> xorg-include
Hi XSF,
~ as you might have noticed, we started (at low priority) working on
X.org packages.
The commits you are seeing now are only the proof of concept that we
will use to split the tree in a "sort of" modularized way, using an
approach close to the way in which our Debian kernel is packaged.
There are some differences, but at this point in time, until the concept
is not proved to be working, are somehow irrelevant.
I am now facing a problem that i would like to discuss with the list.
Example scenario:
monolithic tree:
xc/include/libfoo/foo.h
xc/include/libbar/bar.h
lsdiff debian/patch/XXXfix_foo_bar_due_to_baz.diff
~ xc/include/libfoo/foo.h
~ xc/include/libbar/bar.h
and this is supposed to compile and work fine, since the new version of
the libraries are patched and built at the same time.
- ---------
Modularized tree (files are not patched coming from xorg-source-include):
xc/include/libfoo/foo.h
xc/include/libbar/bar.h
lsdiff libfoo/debian/patch/XXXfix_foo_due_to_baz.diff
~ xc/include/libfoo/foo.h
lsdiff libbar/debian/patch/XXXfix_bar_due_to_baz.diff
~ xc/include/libbar/bar.h
(note that there might no be xc/include/libfoo at all)
bang! now both libfoo and libbar either will not compile properly due to
foo.h and bar.h not being patched at the same time or they will not work
properly for the same reason.
Now I can see four possibilities to unroll this problem:
1 the xorg package that generates all the xorg-source packages will ship
~ a patched tree.
~ - Pro: all the patches will be applied at the same time to the entire
~ tree therefor it's easier to track them.
~ - Con: patches will not be splitted (and this will only the delay the
~ problem when a source will gain its own independency.
~ - Con: it requires an upload of more than 100MB of arch: all packages
~ each time we change a patch, that is a waste of bw to all the
~ mirror.
~ - Con: xorg packages will need a more strict control of build-deps,
~ that will mostlikely end up in confusion and temporary FTBFS.
2 Create a package called xorg-patched-include from xorg-source-include
~ used only internally as build-dep.
~ - Pro: all the patches will still be applied at the same time in one
~ place.
~ - Pro: it will avoid a 100MB upload each time.
~ - Con: patches are still not splitted.
~ - Con: xorg packages will still need a more strict control of
~ Build-deps.
3 Split the includes at subfolder level (same as programs/ or libs/)
~ - Pro: all patches will be available within the proper package.
~ - Pro: patches will be splitted.
~ - Pro: less confusion for people that will try to build xorg from
~ sources.
~ - Pro: much deeper control of what build-dep on what and why.
~ - Con: duplicate patches. We will have to keep in sync more patches
~ in different packages. (given of course that the above scenario is
~ true and probably it is.)
~ - Con: more xorg-source-include-* packages, but they are handled
~ automatically.
~ - Con: possibly more complex build-deps.
4 Leave the includes all in one source package as it is now
~ (xorg-source-include)
~ - Pro: all patches will be available within the proper package.
~ - Pro: patches will be splitted.
~ - Pro: less confusion for people that will try to build xorg from
~ sources.
~ - Con: duplicate patches.
Considering that our target is to get the source as splitted as possible
I think that solution number 3 will be the best one to let a source gain
its own independency as fast as possible.
tho it will need more maintaince our side, but i am pretty sure that we
can manage to script these kind of sanity checks.
I will be pretty much glad to hear other opinions so that the work can
move forward.
Thanks
Fabio
- --
<user> fajita: step one
<fajita> Whatever the problem, step one is always to look in the error log.
<user> fajita: step two
<fajita> When in danger or in doubt, step two is to scream and shout.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBa4WyhCzbekR3nhgRAjCrAKCE8tfrORlzRYiDPnjUX64W6OiJVACfQX1o
pLcrHZ86GTAwnjeBjy8Cy1g=
=4v4m
-----END PGP SIGNATURE-----
Reply to: