From ead7356b8995be1311be33710e28239c0dd0be28 Mon Sep 17 00:00:00 2001 From: Diego Elio Pettenò Date: Sat, 30 Dec 2006 02:36:37 +0000 Subject: Commit the first draft for the documentation, only introduction for now. svn path=/trunk/; revision=22 --- doc/index.docbook | 15 +++++++++ doc/introduction.docbook | 82 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 97 insertions(+) create mode 100644 doc/index.docbook create mode 100644 doc/introduction.docbook diff --git a/doc/index.docbook b/doc/index.docbook new file mode 100644 index 0000000..2793590 --- /dev/null +++ b/doc/index.docbook @@ -0,0 +1,15 @@ + + +]> + + + + + autoepatch documentation + + +&intro; + + diff --git a/doc/introduction.docbook b/doc/introduction.docbook new file mode 100644 index 0000000..fe95d84 --- /dev/null +++ b/doc/introduction.docbook @@ -0,0 +1,82 @@ + +Introduction + + +To make the software as portable as possible, back in the days, GNU +created the autoconf package, that allowed them to discover the +features of the compiler and of the C library they were building, so +they could build the same code over different operating systems and +platforms. + + + +When the complexity of the software started to arise, to autoconf it +was added a software to make simpler writing the makefiles, too, which +is automake. But one of the most complex problems was writing shared +libraries (or rather shared objects are they are called in UNIX +world), because the rules for those might change a lot between +operating systems and compilers: position independent code, shared +object names, compiler switches and so on. To resolve this issue, GNU +libtool was created. + + + +Unfortunately considered the complexity and the variety of the rules, +GNU libtool ended up being a very complex piece of software, and to +make it worse, it had to be written in a portable sh subset, which can +be difficult to read, not only to write, and then problems and errors +in code aroused, obviously. + + + +For this reason, Gentoo Linux had always to cope with many problems +that were caused by software whose package was prepared with a broken +version of GNU libtool... some problems were caused by simple +non-portable syntaxes, others by unsafe permissions on temporary +files, or because libtool didn't support some targets present and +supported in Gentoo (like uClibc), or again because we want to +bend the default rules to suit our needs better (for Gentoo/FreeBSD +for instance). + + + +To avoid having to patch all and every package with a similar patch to +fix libtool misbehavious, libtool.eclass and elibtoolize functions +were created. This eclass uses the patches present in the ELT-patches +directory, trying them one by one, to fix libtool for what we need. + + + +Unfortunately there are issues with this design: we're bound to the +portage tree for the patchsets, there's a logical size limit because +we're using the Portage Tree itself as a patch repository, and the +changes to patches and behaviour go live directly on all the ebuilds +at the same time, so there's no prope way to get a patch in "testing". + + + +And even if the eclass was created thinking about libtool, there are +many use cases that could be handled in a similar way, because there +are classes of packages that simply suffer from a common problem that +can be fixed with a simple similar patch (KDE packages, proper GNU +packages, GNOME packages, ...). + + + +Beside the technical issues, there are also a few maintainership +issues, as the libtool eclass is pretty complex, and there is no +maintainer currently appointed to take care of it; this means that if a +problem arise or a new patch has to be added, someone has to try to +get a clue about the eclass to start with. + + + +To fix these issue and to improve the points where there's space to +improve, the autoepatch project started, with the objective to provide +a simpler implementation for an elibtoolize workalike program, +disengaged from eclasses and the portage tree, that could be hooked up +inside Portage itself, so that ebuilds haven't to be aware of its +presence anymore. + + + -- cgit v1.2.3-65-gdbad