diff options
Diffstat (limited to 'doc/standalone.docbook')
| -rw-r--r-- | doc/standalone.docbook | 56 |
1 files changed, 0 insertions, 56 deletions
diff --git a/doc/standalone.docbook b/doc/standalone.docbook deleted file mode 100644 index 3c8925a..0000000 --- a/doc/standalone.docbook +++ /dev/null @@ -1,56 +0,0 @@ -<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> |