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
|
<chapter id="standalone">
<title>Reasoning for a standalone package</title>
<para>
There are many ways to accomplish the same result. Why the choice was
done toward a standalone package, that would require a new ebuild, and
a tarball, and so on? There are a series of reasons why this approach
is probably the best compromise between the weight of maintainership
and the ability to do 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; 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 and 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; there's no security because neither the
eclasses nor the patches are signed or signable (at the current time
at least).
</para>
<para>
Another option would be to ship the logic code with either a
standalone package or portage and then ship the patches with the RSync
tree, but this leaves us with the security issue (although it might be
possible to find a solution to this), 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"), 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; 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 told by an emerge --info which version of the package
is used once the profiles are instructed to.
</para>
<para>
Probably the worst drawback is that there's the need of a standalone
repository to contain the logic and the patches, but also this can be
considered an advantage as that allows us to branch it when moving to
a stable target.
</para>
</chapter>
|
GitWeb
