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. >> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio