On Mon, Jul 29, 2013 at 11:16 AM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 07/29/2013 11:10 AM, Tom Rondeau wrote: >> >> On Sun, Jul 28, 2013 at 6:40 PM, Alexandru Csete<oz9...@gmail.com> wrote: >>> >>> On Fri, Jul 26, 2013 at 4:27 PM, Tom Rondeau<t...@trondeau.com> wrote: >>>> >>>> On Thu, Jul 25, 2013 at 7:28 AM, Alexandru Csete<oz9...@gmail.com> >>>> wrote: >>>>> >>>>> Greetings, >>>>> >>>>> Yesterday, I started playing with pybombs and fixed a few recipes >>>>> related to gr-osmosdr. During this process I made gr-osmosdr depend on >>>>> uhd, rtl-sdr, osmo-sdr, hackrf and gr-iqbal. I did this to ensure that >>>>> all supported input devices are made available to users. It should be >>>>> noted that all these packages are optional and gr-osmosdr would work >>>>> just fine with gnuradio as the only dependency still supporting >>>>> funcube dongles and I/Q file sources. >>>> >>>> Alex, >>>> >>>> Thanks for the report and all of the patches you submitted to PyBOMBS. >>>> It's a new project and will definitely need wide-spread testing and >>>> help to get working well on various systems and for various needs. >>>> >>>>> Later I will be adding a recipe for the gr-fcdproplus OOT source block >>>>> and add that as a gr-osmosdr dependency as well. This works well for >>>>> now since all these driver libraries are recent and well maintained. >>>>> However, as time goes this driver list will grow and the risk of >>>>> something breaking will increase. This made me think whether there may >>>>> be a need for a weaker dependency specification, something like the >>>>> "recommends" section in deb packages or the "variant" in macports? >>>> >>>> The 'recommends' is a very interesting idea. I'm not sure I like >>>> forcing the installation of all of the base drivers for gr-osmosdr, >>>> but if we have a menu-driven section if the dependencies are >>>> recommended and allow the user to select which, if any, to also >>>> install, that'd be great. >>>> >>>> Would you open a feature issue on the PyBOMBS Redmine page suggesting >>>> this? >>> >>> Done. >> >> Thanks! >> >>>>> As an alternate solution here& now, we could just remove all optional >>>>> >>>>> dependencies from the gr-osmosdr recipe and instruct users to install >>>>> their preferred driver libraries prior to installing gr-osmosdr. Or >>>>> create meta-recipes that would provide the most common combinations. I >>>>> don't know what would be the best solution. >>>> >>>> I'm not sure, either. Until we figure out a concept like the >>>> recommendations, my preference is to not include them as dependencies, >>>> but I could be persuaded out of that thought. I'm guessing Philip >>>> would argue for a meta-layer :) >>> >>> Maybe as compromise we can remove all optional dependencies except >>> rtl-sdr and uhd. That would provide a good default for 95% of the >>> users today and only require rtl-sdr as extra package since the >>> gnuradio recipe already depends on uhd. >>> >>> Alex >> >> I can see that, especially since we have uhd as a dep for gnuradio, >> too. Also, rtl-sdr is lightweight and only depends on libusb, so it's >> a pretty safe one to install. And yeah, I agree, that takes care of >> most people's needs right now. >> >> Tom >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > rtl-sdr is just the device-driver library for RTL dongles. You need > gr-osmosdr as well.
The debate is whether or not to include rtl-sdr and uhd as dependencies to gr-osmosdr. Tom _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio