Packaging and Several Concepts
The other day some of my colleagues were discussing about how to manage a
package. From what I heard:
SUSE decides to use kernel's bundled
instead of the version built out of
DRDB's source tree, which is dropped in
DRDB's new version anyway. The package for this new
DRDB is called
DRDB-user as it only contains the user-space part. The problem rises when a
user of older version of
SLE (SUSE Linux Enterprise) decides to update to this
DRDB-user is said to support some old versions, i.e. for these
versions you can mix up kernel modules from old
DRDB package with newer
DRDB-user. The question is how to do the packaging? (I am totally ignorant
DRDB, so the details might not be exact but the important point here is
I joined this discussion and throughout the course I've come to understand many concepts more clearly than before: no overlap among packages, different packaging methods, the meaning and differences between "Obsoletes" and "Conflicts"
How to design packages?
The most intuitive and also best way should be just to divide the old
package into two:
DRDB-km. In this way,
DRDB-user is just
the new package and can be upgraded separately if needed. So far so good. But
what if we don't want to change the old package? Why? In retrospect, I think
it's truly evil to have thought in that way, but back then they wanted to limit
the maintenance burden by reducing the number of packages.(Oh, I did support
this view…, I understand…) And then we fell into the rabbit hole.
Packages should never overwrite each other.
The first idea was to have
DRDB. This won't work. No
matter how the dependency links are designed. Naive I was, I believed
carefully-crafted dependency would avoid any package breaks. Even cyclic
dependency was considered. As an afterthought, no overlap between packages is
actually the number one rule of packaging. In this case, just think of
DRDB-user is installed.
However, this is the quickest solution. So if the use cases of mixing up old
DRDB with new
DRDB-user are only few, then it might not be necessary to
DRDB-km. To tell the sysadmin to be extra careful or add some warning
to the (un)installation/update message would be enough.
Overwriting while packaging.
In the build&install phrase of packaging, build old
DRDB and also new
DRDB first, then
DRDB-user, overwriting same files at
the same time. At last you pack everything up and name it
DRDB. This method
should work in principle, but it's bizarre and in reality we maintain a new
package even though it has an old name.
When talking about making new packages, we got confused on "Obsoletes" vs "Conflicts". I'll put up two good references:
replaces is just the
In common, they all remove the designated packages. – here is the cause we get confused.
But have different purposes:
Obsoletes prescribes an upgrade, so it's
automatically done by the packaging system.
Conflicts prevents installation
and these packages are surely not in the upgraded package list.
I didn't follow this discussion later and don't know what they've decided to do in the end. In reflection, I realized how little I knew about packaging and how real-life politics can affect engineering choice. The mentality to avoid designing necessary new packages might come from this fact: whoever introduces the package is likely to be responsible for maintaining it. And there are already A LOT of packages at each one's hand. Further, even the evil package-overwriting method might be useful, if only one or two customers need that special mix setup.