Package Details: openafs 1.8.13.1-1

Git Clone URL: https://aur.archlinux.org/openafs.git (read-only, click to copy)
Package Base: openafs
Description: Open source implementation of the AFS distributed file system
Upstream URL: http://www.openafs.org
Licenses: IPL-1.0
Conflicts: openafs-features
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 61
Popularity: 0.000000
First Submitted: 2006-02-01 17:18 (UTC)
Last Updated: 2024-12-21 09:26 (UTC)

Latest Comments

« First ‹ Previous 1 .. 9 10 11 12 13 14 15 16 17 18 19 .. 32 Next › Last »

cptiglo commented on 2014-03-22 10:04 (UTC)

Sorry for so much input, but I just figured out a more elegant solution than creating a dummy Makefile by just setting the dkms clean command to CLEAN="rm -f openafs.ko && [ ! -f Makefile ] || make clean" so that the "make clean" is only run if a Makefile exists.

cptiglo commented on 2014-03-21 13:13 (UTC)

The problem is that there exists no Makefile before the first "./configure". One solution would be to create a dummy Makefile by inserting # Create dummy Makefile if none exists [ -f ${pkgdir}/usr/src/${_srcname}-${pkgver}/Makefile ] || \ printf "clean:\n\t@echo 'Nothing to clean yet.'" > ${pkgdir}/usr/src/${_srcname}-${pkgver}/Makefile at the end of the package() function.

cptiglo commented on 2014-03-21 11:36 (UTC)

Doing a "dkms install openafs/1.6.6" in the end successfully builds the module, but in the beginning I do get a message: cleaning build area....(bad exit status: 2) Is it somehow possible to fix this?

cptiglo commented on 2014-03-21 09:26 (UTC)

Just one more thing concerning /extramodules: If two kernel directories symlink to the same extramodules, dkms should only build the module once for both of them, which is exactly the behaviour we would like to have. I think without putting the module into /extramodules dkms would rebuild for every minor release of the kernel.

cptiglo commented on 2014-03-21 09:19 (UTC)

Thank you!

Bevan commented on 2014-03-20 21:50 (UTC)

You are right. There can be two or even more extramodules directories in case some package (like openafs-modules ;)) has still a module lying around. I will include your change. Regarding DEST_MODULE_LOCATION: /extramodules was my first thought here, too. This would become an issue, if someone has two kernel versions installed where /extramodule points to the same location. But I don't think this should ever be the case, so I'll include that change, too. Thanks :)

cptiglo commented on 2014-03-20 21:33 (UTC)

Okay I can live with that. Then for the openafs-modules I would suggest doing _extramodules=$(cd /usr/lib/modules && ls -dt extramodules-*-ARCH | head -1) which should always give the path to the latest extramodules directory. I think after a major kernel update and before reboot the old extramodules directory in /usr/lib/modules will still exist. Concerning the dkms package: Could you change DEST_MODULE_LOCATION[0] to DEST_MODULE_LOCATION[0]="/extramodules" ?

Bevan commented on 2014-03-20 21:04 (UTC)

Hi, I thought about it and decided against a fixed kernel version in the PKGBUILD. I agree that this would be the right way in [community], but here in AUR it is different I think. If a fixed version was specified updating the kernel package would be a pain. You would first have to remove openafs-modules (because it depends on the old kernel package), then update the kernel, then build&install openafs-modules again with the updated PKGBUILD. Also this would not completely solve the issue of silently failing openafs. Sometimes the ABI also changes in minor kernel releases what makes a rebuild of the module necessary. So you still would have to be cautious after every kernel update. I did a few changes to the packages, including many of your suggestions and will probably release them on weekend if I cannot find any show-stopper. Thanks for all your feedback! :)

cptiglo commented on 2014-03-20 12:55 (UTC)

At least _I_ think it should be done in the "right" way. First of all because it's annoying that after a major kernel release openafs silently stops working, but also because I want to have openafs in the community repository sooner or later and it will most probably not be accepted if it's not packaged in the "right" way. Concerning your cons: I think these are just the reasons to have an additional dkms package for people who can't wait updating their kernel or use a different kernel version.

Bevan commented on 2014-03-20 10:58 (UTC)

Hi. Thanks for your input :) I'll apply the changes to openafs and test them. I'm a bit hesitating to put the kernel version into the PKGBUILD of openafs-modules. Pros: - it's the "right" way to do it - openafs most of the time needs patches for newer kernel versions anyway Cons: - I would have to modify the package here exactly when a new kernel hits [core]. I obviously cannot manage that - People using [testing] or other kernels would always have to edit the PKGBUILD if they're using another kernel version Another idea: Couldn't we just look for /usr/lib/modules/extramodules-*-ARCH and extract the version from that? Or are there chances that there is more than one extramodules dir? Should not be the case using the official kernel packages because you always only have one of them installed.

« First ‹ Previous 1 .. 9 10 11 12 13 14 15 16 17 18 19 .. 32 Next › Last »