diff options
Diffstat (limited to 'doc/standalone.docbook')
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>
-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.
-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).
-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.
-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.
-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.