> 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 > snapshot > 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. > 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 system like cmake or similar to try to address this, or at least using the packaging components. Some reorganization of the build process would probably be desirable to really take advantage of that, but I can't say that that would be unwelcome. The current setup is awfully clunky, and the meta-build system would allow generation of different types of packages from the same source (at least with cpack, you can generate RPM, .deb, Solaris, AIX and Windows packages fairly easily from the same packaging description file). You could also do this fairly easily without converting the whole package to cmake (you just need a comprehensive list of what binaries/scripts are needed 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 some of that tooling could be pushed upstream. > Also, there is a question of what version number to put on snapshots so that > they will sort properly between "real" releases. Suggestion: use a different package name to clearly distinguish between stable and beta releases (ie, something like openafs-beta instead of openafs). You could then use the same release/versioning information plus a build date or something to identify the package version. It would also clearly indicate to users that they are NOT getting the "stable" release and they shouldn'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). At least on Linux, that wouldn't be too hard to do (just a different spec file for RPM, and similar for Debian). The cmake overlay I mentioned above could 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 clearly different name and version without a lot of rework). _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
