1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
<chapter>
<title>Introduction</title>
<para>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
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).
</para>
<para>
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.
</para>
<para>
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".
</para>
<para>
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, ...).
</para>
<para>
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.
</para>
<para>
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.
</para>
</chapter>
|
GitWeb