diff options
author | Diego Elio Pettenò <flameeyes@gentoo.org> | 2006-12-30 07:12:12 +0000 |
---|---|---|
committer | Diego Elio Pettenò <flameeyes@gentoo.org> | 2006-12-30 07:12:12 +0000 |
commit | 08263950ccba18fa90b9ab5e975edfbbe711915a (patch) | |
tree | c61011d5f052701740084101bfdae919973e58bf /doc/standalone.docbook | |
parent | Add id value. (diff) | |
download | autoepatch-08263950ccba18fa90b9ab5e975edfbbe711915a.tar.gz autoepatch-08263950ccba18fa90b9ab5e975edfbbe711915a.tar.bz2 autoepatch-08263950ccba18fa90b9ab5e975edfbbe711915a.zip |
Add a chapter on the reasons why a standalone package was chosen instead of other solutions, and start one about the way autoepatch works.
svn path=/trunk/; revision=24
Diffstat (limited to 'doc/standalone.docbook')
-rw-r--r-- | doc/standalone.docbook | 56 |
1 files changed, 56 insertions, 0 deletions
diff --git a/doc/standalone.docbook b/doc/standalone.docbook new file mode 100644 index 0000000..3c8925a --- /dev/null +++ b/doc/standalone.docbook @@ -0,0 +1,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> |