Feature #2379
package as .deb
0%
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.
History
#1 Updated by laforge over 2 years ago
- Assignee set to Osmocom CNI Developers
#2 Updated by laforge over 1 year ago
- Assignee changed from Osmocom CNI Developers to fixeria
#3 Updated by laforge 11 months ago
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?
#4 Updated by osmith 11 months ago
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.
#6 Updated by laforge 11 months ago
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, ...
