[OpenAFS] buildbot and packages

[David Boyes]

> Most distro/OSes have their own packaging system, and it would seem that
> life would be easier for such potential testers if they could install a s=
napshot
> of openafs within their packaging system.

I would argue that there's no value at all in doing this if this isn't the =
case. Installing things that don't play nice with the packaging system is a=
 guaranteed recipe for disaster, or at least messing up a system in really =
unhelpful ways, and if the goal is improving testing, there's going to be a=
 lot of install/uninstall cycles. Working with the packaging system is the =
best way to do that.=20

>  However, the packaging files in
> our tree are frequently stale (since we are not the canonical source for
> them), so this could place a new burden on our distro maintainers if we
> choose to take this route.

There have been several discussions in the past on using a meta-build syste=
m like cmake or similar to try to address this, or at least using the packa=
ging components. Some reorganization of the build process would probably be=
 desirable to really take advantage of that, but I can't say that that woul=
d be unwelcome. The current setup is awfully clunky, and the meta-build sys=
tem would allow generation of different types of packages from the same sou=
rce (at least with cpack, you can generate RPM, .deb, Solaris, AIX and Wind=
ows packages fairly easily from the same packaging description file).=20

You could also do this fairly easily without converting the whole package t=
o cmake (you just need a comprehensive list of what binaries/scripts are ne=
eded and where they need to go) by calling the existing build system inside=
 cmake and adding the packaging info to create packages from the output. We=
 already do something similar here for our own internal builds, so maybe so=
me of that tooling could be pushed upstream.=20
=20
> Also, there is a question of what version number to put on snapshots so t=
hat
> they will sort properly between "real" releases.

Suggestion: use a different package name to clearly distinguish between sta=
ble and beta releases (ie, something like openafs-beta instead of openafs).=
 You could then use the same release/versioning information plus a build da=
te or something to identify the package version. It would also clearly indi=
cate to users that they are NOT getting the "stable" release and they shoul=
dn't expect everything to work perfectly (not that that will stop the "must=
 have bleeding edge" nutcases, but at least there's a clear "I told you so"=
 warning).=20

At least on Linux, that wouldn't be too hard to do (just a different spec f=
ile for RPM, and similar for Debian). The cmake overlay I mentioned above c=
ould also easily support this (the control files are plain text, and a bit =
of sed-fu would be sufficient to be able to generate packages with a clearl=
y different name and version without a lot of rework).=20