linrad

[Iain R. Learmonth]

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 at fsfe.org            w: iain.learmonth.me
x: irl at jabber.fsfe.org     t: EPVPN 2105
c: 2M0STB                  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/fedora-hams/attachments/20150406/9ef2a351/attachment.bin