Repository Goals

From LSDevLinux
Jump to: navigation, search


There are various goals that are necessary for a repository like this to meet.

First, this repository must be safe to use. That is, the normal use of the repository and the packages in the repository should not break a system an installed system in any way. If it isn't safe to use, we have no choice but to actively dissuade people from using it which kind of defeats its purpose for existing.

Secondly, the repository and the package versions contained should not break established upgrade paths. For example, if there is a normal upgrade path between Ubuntu Hardy and Intrepid, people who use this repository should still be able to upgrade from Hardy to Intrepid using that normal path without resorting to pinning or other techniques that average users are likely to be unaware of.

In my mind, the above two goals are absolutely fundamental for a repository that is intended for people to actually use for real work.

However, there are also conflicting goals for a repository that can't be met with a single distribution. For example, on one hand it is desirable to distribute testing versions of software in order for early testing of pre-release software to take place as easily as possible. On the other hand, there are users who do not have time to be software developers and would simply like to use software that has been tested by others. These two goals are irreconcilably different. Also, there are users who would like to have a reasonably tested version and because of high bandwidth costs can't afford to be downloading a new copy of packages the size of OpenOffice every other day.

So, we have at least two conflicting goals:

  1. distribute testing versions of software to those who can test
  2. distribute released versions of software who want to use it for real work.

However, even though these two goals are at odds with each other, with care they can both be solved in the same repository.

Goal Summary

  1. Safe to use
  2. Does not break normal upgrade path
  3. Distributes testing versions of software to testers
  4. Distributes release versions of software to actual users

Direct Implications

If these four goals are assumed, then there are some implications that need to be dealt with.

1) This really just implies 2 and 4.

2) Upgrades should still be able to happen cleanly if this repository is not included as one of the sources when upgrading. This has implications with the version numbers of the packages. Since in general it is necessary for packages to "upgrade" when moving from one release to the next in order to make sure that the correct library dependencies are linked, package version numbers must have a strict ordering so that this upgrade will happen correctly. In the case that this repository is not included as a source during the upgrade, it is possible that an older version of the software may be installed during the upgrade if the upstream release includes an older version. However, once the release upgrade is finished and this repository added back in as a source, the new version of the software will end up installed.

3) implies that test versions, even pre-alpha may be included.

4) implies that at the bare minimum, the upstream developer of the software believes that the software is ready for use and is unlikely to cause loss of data. If the upstream does not advertise a certain version as being of "release quality" then in general it should not be included. Thus, no beta versions of software should be included.

Obviously, there is a fundamental conflict between 3) and 4). This clash can be handled by using different distributions each addressing these conflicting goals.