Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
linux support
See original GitHub issueHow should Linux support work?
One way would be to have some sort of build system that always carefully only links against libc 5, does everything statically, etc, and builds everything into a big binary.
Another would be to instead have multiple backends for .rpm, .deb, etc. I imagine that this would be different from bdist_rpm, bdist_deb et. al. by doing some automatic determination of what the package dependencies ought to be by looking for shared library dependencies. Despite the fact that this would not be nearly as self-contained, it might be more practically useful to begin with.
Issue Analytics
- State:
- Created 8 years ago
- Comments:14 (10 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@loganasherjones AFAICT, we should be able to support both (along with raw RPM/DEB packaging as well, for that matter). From my perspective, it’s just a matter of having someone with expertise in one of those packaging toolchains building out the application template and describing the compilation/packaging process.
Given how different deb, rpm and other Linux distros (eg Arch) are, does it make sense to have separate commands for the different targets? I was thinking
linux-deblinux-rpmandlinux-arch. I run Arch, so I’m interested in trying to get briefcase to generate an Arch PKGBUILD or.tar.xzpackage.