Hi Troy,
On Dec 21, 2010, at 20:46 , Troy Dawson wrote:
> Stephan Wiesand wrote:
>> I put up a first proposal: http://www.ifh.de/~wiesand/SL6/openafs.SLx-1.5.78-86.src.rpm
>> Build instructions are in the package description, and the changelog should be fairly complete. The major changes with respect to our current 1.4 packages are:
>> 1) It's openafs-1.5.
[...]
> I'm good with openafs 1.5, no complaints here.
great. Again, we can switch back to 1.4 if serious problems are found during testing that cannot be resolved swiftly. But I bet we'd get very good support from the developers in this case.
>> 2) The default cache location moved from /var/cache/openafs to /var/cache/afs.
>> That's because on SL6 with SELinux enabled, the client is governed by the targeted policy. That's a good thing. But it also means we either have to stick with what the policy supports, or [have our users] jump through extra hoops. And the policy supports having the cache in /var/cache/afs or /usr/vice/cache, but not in /var/cache/openafs.
>
> We'll have to document this, but that's not too hard.
The alternative would be to use "semanage fcontext -a -e /var/cache/afs /var/cache/openafs" in a trigger in the client package. Or document this (sites changing the cache location have to do it anyway, unlesss they turn off SELinux).
In any case, it might be a good idea to restorecon the important files/directories (/afs mountpoint, afsd executable, init script) upon first time installation, to make sure the client can be started even if restorecond is not running (which it no longer does by default, it seems). Is this a good idea or a stupid one?
>> 3) Support for SL3/4 was removed. The SRPM only works on SL5/6.
>> This allowed for a major simplification of the spec file. SL4 support could be retrofitted with (quite) a bit of work, but would also complicate the spec significantly. Given the limited TTL of SL4 (~ 1 year), I left it out for the time being.
>
> No complaints here.
> I assume that a openafs 1.4 client can connect to a 1.5/1.6 server.
Yes, it can. Even a 1.2 client should be able to. And even older ones, but I personally wouldn't care.
>> 4) The openafs-debug package was renamed to openafs-plumbing-tools.
>> Suggestions for better names are welcome.
>
> I'm curious about this change.
> All of the packages in this rpm have debug in the name, except state_analyzer. Why the name change?
Well, I've never really liked the name -debug since the first thing that happened after introducing the package was you confusing it for the -debuginfo one. The content is really not only useful for debugging, but also for monitoring and for manipulating things in a way the standard toolset doesn't support. Some of the tools in there can be pretty harmful if used without care by anyone not really knowing what he's doing but having the privileges to do harm. They can be immensely useful if things go wrong, though. Typically, that's not the situation in which you want to start building from source to get your hand on the tool you need, hence this package.
But if you'd rather stay with -debug, I'll gladly change the name back.
>> 5) It builds KABI-dependent kmod-openafs packages.
>> While the ability to build our traditional kernel-module-`uname -r` packages is still there (and required on SL5, I think, because KABI tracking kmods make little sense there for openafs), this is probably the way to go for packaging the kernel module on SL6 and beyond.
[...]
>> When implementing those kmods, I started out from what the elrepo folks are doing, but made a few significant changes. Any comments are very welcome:
>> o there's a single spec for the userland/kernel-module/kmod packages
>> o a -debuginfo package is built (taking care the name makes sense)
>> o weak-modules is called with the --no-initramfs switch
>> o an abbreviated form of the kernel release is appended to the kmod-openafs package release
>> The last change was made because I just couldn't stand it that the SRPM could be rebuilt against a different kernel (possibly with an incompatible ABI), resulting in packages with exactly the same n-v-r but very different content. And to avoid the need to touch the spec every time modules for a new kernel are rolled out. So what happens is that the release part of the target kernel's `uname -r`, without the gratuitous architecture and the dist tag, is appended to the kmod's release. This allows for clean updates when the module is built for a later kernel, and to install the right debuginfo package if you have to. But it's different from elrepo.
[...]
> This is possibly the greatest part of this source rpm. Thank you for making an rpm that is able to do both the old and new way. I know it's a lot of work.
Glad you like it.
Since I have very limited experience with these kmods, it would be really great to hear from the elrepo folks whether/why the above changes are stupid. Alan, Akemi, Dag, ..., are you reading?
>> 6) The general aim is to make the SL packages more compatible with the openafs.org ones. As compatible as possible. Identical, if possible. The proposed SRPM already reflects this by moving files into the same subpackage as the openafs.org spec where it makes sense, building with the same compiler flags etc. I'm also going to work with the openafs.org folks (by submitting patches to their SCM) to make things more consistent from both ends. But that's going to take a while, and for SL6 we'll have to take decisions:
>> The next step in making things more compatible would be to rename the init/sysconfig files:
>> o /etc/init.d/afs would become /etc/init.d/openafs-client
>> o /etc/init.d/afs-server would become /etc/init.d/openafs-server
>> o /etc/sysconfig/afs would become /etc/sysconfig/openafs
>> And then, the content of those would have to be synchronized. Which would basically mean throwing away most of what we have today (automatic cache size, automatic home cell if it's the DNS domain, ...).
>> So the question is what's more important to our users: backward compatibility with previous SL releases, or compatibility with openafs.org. Any input?
>
> If we are going to do it (come in line with openafs.org) then now is the time to do it.
I agree. There are however limits to what we can achieve in this respect before the SL6 and OpenAFS 1.6 releases. If this was the last detail that made our packaging different, I'd say let's get it over with now. But that's not where we are. As a trivial example, openafs.org don't package livesys. We've had that in since an eternity, and I think it's useful. I'd rather work on getting it into the openafs.org packages than removing it from the SL ones. In the course, I may learn why it shouldn't be packaged at all, who knows. Once all issues like this one are settled, we should go for 100% compatibility.
> We can always tell our users it is a result of upgrading from 1.4 to 1.5/1.6.
It wouldn't be entirely correct, though ;-)
> Most users are used to some changes that come about because of a major release update.
Yes, but they also appreciate it if things don't change unless there's a good reason for it. (See my rant on the beta list about changing the output of "uname -r" on RHEL6 because a single Fedora home user wanted to dual-boot 32-bit and 64-bit with a shared /boot partition several years ago ;-)
It's been a virtue of the SL AFS packages that very few incompatible changes were made since SL3. If a site had a cfengine recipe/config rpm/puppet manifest/quattor component/some script/whatever to configure the client on SL3, it should still work on SL5, and it could still work on SL6 in 2017. There's nothing fundamentally wrong with what we have, I think.
> This might mean that we make a few SL_ rpm's that users can install so that AFS behaves the way it used to.
That's doable, but ugly. Unless you want to support this forever, sites will have to switch at some point, and could just as well do it now.
I'm not opposed to this change, and I'm prepared to do it. I'm just a bit hesitant to do it without either some user feedback or a good reason why it's beneficial to break backward compatibility now and not in 2012 when we gear up for SL7. Unlike renaming the -debug package, this change does have a significant impact. Things may look different then, and the packagings won't have converged completely much before anyway.
- Stephan
--
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany
|
