Hi Leif, On Mon, Apr 06, 2015 at 09:30:05PM +0200, Leif Asbrink wrote:
I would avoid putting messages into your code that talk about specific distributions. Today such things are in the configure script. In case a uset selects for example to use a BladeRF, Linrad would try to load libbladeRF.so and if it fails the message is: Could not load library libbladeRF.so Did you run ./configure after installing this library?
the configure script contains the information about how to install everything needed to the extent that I know about it. The hint at the end of the script is: Missing or not working libraries (non fatal.) For information, type ./configure --with-help
Ok, cool. So what I usually do with Debian packaging is make sure all the options are compilied in unless there are insane options that only 3 people in the world are going to user ever. If you move to dynamic loading of libraries, then they would be made available in the build environment when building the package, but on the package itself the libraries would be "Recommends" instead of "Depends" (RPM doesn't appear to have anything similar to the Debian recommends, and I think autodependencies would pick up the libraries as "Requires" anyway, so I'm not sure dynamic loading helps with Fedora). This would mean that on Debian at least, linrad could be installed without optional extras if that is desired, though by default apt does install packages in "Recommends".
A message to tell you what is missing, and maybe a link to a webpage that explains where the package can be found for different distributions would be better. We don't want to make it harder for other distributions to package your code and a webpage can be easily updated with contributions from others after the package is released. Do make sure the URL can stay the same for a long time though. It would be nice if that URL could be managed by others. I have tested Debian, Ubuntu, Fedora, Suse, Mageia, Mandriva Slackware, PCLinuxOS, Gentoo and Sabayon. There are also a couple of hints for Mac OSX. I have failed to install several other distributions and I have not verified all the installation instructions in several years so there are probably many obsolete packages.
Maybe this: echo "Old Fedora: yum install libusb1-devel" echo "New Fedora: yum install libusbx-devel" One or the other should install libusb-1.0.so but I guess the package name could have changed again??
Hmm. This is an interesting problem. What you really want is a distribution independent .so to package name lookup system. I'm not entirely sure how to solve this.
OK. I post releases here occasionally: http://www.sm5bsz.com/linuxdsp/linrad.htm The development code is likely to contain new bugs now and then so packaging releases should be the appropriate strategy.
Cool. When I filed the RFP bug in Debian I see I was looking at 04.02, but you've since released 04.05. This 04.05 release is the one that would be packaged most likely.
Please read the entire text: "It is free for anyone for any purpose. Copyright laws are complicated and to make sure I will not change my mind and claim copyright Linrad comes with the MIT license starting with version 03-45. By granting a very permissive license to anyone who has obtained a copy of Linrad there should be no doubt that the freedom to use linrad or parts of the code for any purpose will remain for ever."
"Use the code for any purpose" means ANY purpose such as distribution, modification, etc. To further clarify the files come with the MIT license. There is a zz-COPYRIGHT.txt file containing the MIT license. This is the most free license I have found.
Oops. Sorry, was reading in a hurry. Yep, no licensing problems here! Thanks, Iain. -- e: irl@fsfe.org w: iain.learmonth.me x: irl@jabber.fsfe.org t: EPVPN 2105 c: 2M0STB g: IO87we p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49