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
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
<chapter id="introduction">
<title>Introduction</title>
<sect1 id="motivation">
<title>Motivation</title>
<para>
To make software as portable as possible, GNU developers created the autoconf
package, which 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>
However, as software grew more complex, the need arose for a simpler method of
writing makefiles was added to autoconf: automake. 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 (PIC), shared object
names, compiler switches, and so on. To resolve this issue, GNU libtool was
created.
</para>
<para>
Unfortunately, given the complexity and 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, let alone
write, and led to problems and errors in code.
</para>
<para>
Because of these issues, Gentoo Linux has always had to deal with packages that
were prepared with broken versions of libtool. Some problems were caused by
non-portable syntaxes, others by unsafe permissions on temporary files, or
because libtool didn't support some targets present and supported in Gentoo
(such as uclibc), or because we want to bend the rules to better suit our needs
(Gentoo/FreeBSD for example).
</para>
<para>
To avoid having to patch each and every package with a similar patch to fix
libtool misbehaviors, the libtool.eclass and elibtoolize functions were created.
The eclass uses patches present in the ELT-patches directory and tries them one
by one to fix libtool.
</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
behavior go live directly on all the ebuilds at the same time, so there's no
proper way to get a patch in "testing."
</para>
<para>
Even though the eclass was created with libtool in mind, there are many use
cases that could be handled in a similar way, because there are classes of
packages that suffer from a common problem that can be fixed with a simple
similar patch. (KDE packages, proper GNU packages, GNOME packages, etc.)
</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 arises or a new patch has to
be added, someone has to first learn about the inner workings of the eclass.
</para>
<para>
To fix these issues, the autoepatch project was created with the objective to
provide a simpler implementation for an elibtoolize workalike program,
disengaged from eclasses and the Portage tree, that could be run from inside
Portage itself, so that ebuilds don't need to be aware of its presence.
</para>
</sect1>
<sect1 id="standalone">
<title>Reasoning for a standalone package</title>
<para>
There are many ways to accomplish the same result. Why create a standalone
package that would require a new ebuild, a tarball, and so on? This approach is
probably the best compromise between the weight of maintainership and the
ability to make changes without involving all the users at once.
</para>
<para>
The current method of storing both the logic code and the patches on the same
CVS module used for the Portage tree (and thus on the rsync servers) is
obviously flawed. The eclass has to know the PORTDIR path; there's no way to
overlay the patches if one has to be changed for some reason. Also, the code
applies to all users at the same time, as the eclass is not versioned for stable
and testing branches the size of patches. Additionally,the logic code is
restricted, because the size of the CVS tree is a main concern, as it already
increases with the increase of the number of packages available. Finally,
there's no security because neither the eclasses nor the patches are signed or
signable at this time.
</para>
<para>
Another option would be to ship the logic code with either a standalone package
or with Portage and then ship the patches with the rsync tree, but this leaves
us with the security issue and with the size constraints that we have with the
current solution. Even if it would be possible to just recode the logic to
allow a separation between testing and stable packages, it would be difficult to
tell from an emerge --info output what the user is using for a given package.
</para>
<para>
By using a separate standalone package it is possible to avoid limits on the
size of both the logic and the patches (that would be on their own archive,
which could just have a "reasonable size"). Furthermore, it is possible to sign
the ebuild in the tree, and thus the digest for the tarball would be signed too,
covering the security issue. Moreover, there can be different versions of the
tarball -- with different patches -- that can have different visibility
depending on keywords and masked state, and it can be easily determined by
emerge --info which version of the package is used once the profiles are
instructed to.
</para>
<para>
Probably the worst drawback is that there needs to be a standalone repository
containing both the logic and the patches, but this can be considered an
advantage as that allows us to branch it when moving to a stable target.
</para>
</sect1>
</chapter>
|
GitWeb