Feature #2379
open
Added by msuraev almost 7 years ago.
Updated about 4 years ago.
Description
Since the introduction of virt-phy, the osmocom-bb becomes generally useful even without specific hw. It would be great to simplify installation of it (at least virt-phy related parts) via .deb similar to the rest of Osmocom projects.
- Assignee changed from 118 to fixeria
I just realized that we still don't have this. It's a bit of a pity. I'm not the debian package expert, but I think we'd probably actually have one debian/ subdirectory for each of the sub-projects, as each of them (virtphy, trxcon, layer23, ...) comes with it's own configure.ac/Makefile.am/etc. anyway.
Or is there a better way? I'm sure one can add tons of overrides in debian/rules and build all of the sub-projects from a single set of packaging rules - but at what advantage? Treating individual sub-directories as separate source packages seems to make more sense to me.
comments, anyone?
laforge wrote:
I'm sure one can add tons of overrides in debian/rules and build all of the sub-projects from a single set of packaging rules - but at what advantage? Treating individual sub-directories as separate source packages seems to make more sense to me.
Ack. The less complex, the better.
Well to me the question would be: why do we have several autofoo projects all around in osmocom-bb? That's the case right? I always found that quite annoying and fixing that would also allow for 1 and only 1 debian/ dir ("to rule them all").
On Thu, Feb 27, 2020 at 10:23:28AM +0000, pespin [REDMINE] wrote:
Well to me the question would be: why do we have several autofoo projects all around in osmocom-bb? That's the case right? I always found that quite annoying and fixing that would also allow for 1 and only 1 debian/ dir ("to rule them all").
Because it's rerally a collection of independnet projects. THere's zero code shared between
'layer23' and 'trxcon', for example. So why build all of them all the time in some integrated
way if they have no relation? And particularly once you go to firmware builds, you end up
with a non-autotools crosscompile project that has no relation to the rest.
The onlything all those programs have in common is that they work on the MS side of the Um
interface, or in the Um interface itself. Some are embedded code for ARM7TDMI, some
are python, some are C, ...
- Assignee deleted (
fixeria)
Also available in: Atom
PDF
