Timeline for What is the standard practice when the developer does not want third party redistribution of a certain free and open source software?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 16, 2020 at 7:00 | comment | added | planetmaker | @muru oh, I see. That of course makes total sense. Thx. | |
| Aug 16, 2020 at 5:33 | comment | added | Archisman Panigrahi | @muru The problem with building from source is, droidcam depends on another package, which is available in the repositories, but droidcam expects it to be installed in /opt. So I will have to manually download, compile and install the dependency in /opt in order to build droidcam binaries (this is why Launchpad build servers cannot build it straight from source). Of course, there must be a way to configure Droidcam not to expect its dependency to be installed in /opt (by modifying Droidcam's source), but I was shipping the binaries to save effort. | |
| Aug 16, 2020 at 3:47 | comment | added | muru | planetmaker I believe pjc50 was responding to this bit from ArchismanPanigrahi: "I was shipping the release tarball containing the prebilt binaries in the deb package". Even if the original developer provides binaries, it's usually expected that Debian packages are built from source. | |
| Aug 14, 2020 at 15:09 | comment | added | planetmaker | Not sure what statement you try to counter. Nowehere anyone said to distribute builds from 3rd-party sources and build services. Yet, it's good practise to have you CI build the packages and thus quickly detect problems - on build service you control. This way it easy for the actual debian maintainer to maintain the package - not much work then needed anymore. It's not like debian doesn't build them on their own CI, too. | |
| Aug 14, 2020 at 14:09 | comment | added | pjc50 | I believe it's poor debian packaging practice to package things which have not been built yourself - you have even less idea what's in them. | |
| Aug 14, 2020 at 8:58 | history | edited | planetmaker | CC BY-SA 4.0 | edited body |
| Aug 14, 2020 at 7:01 | comment | added | planetmaker | They can. They are a full ci/CD solution (see my last paragraph). At least when combined with azure pipelines, but might be without meanwhile | |
| Aug 14, 2020 at 6:58 | comment | added | Archisman Panigrahi | Not having much experience with packaging, I was shipping the release tarball containing the prebilt binaries in the deb package, and provided the source along with it (in principle, one can generate .deb package from source without providing binaries, but this program has build dependencies which are not available in debian repositories, so that will be complicated). This way, to provide an update, I will have to change the release tarball in the debian source, change version number, and upload it to Launchpad. I am not sure if GitHub actions can do something like this. | |
| Aug 14, 2020 at 6:58 | history | edited | planetmaker | CC BY-SA 4.0 | added 1085 characters in body |
| Aug 14, 2020 at 6:53 | history | edited | planetmaker | CC BY-SA 4.0 | added 1085 characters in body |
| Aug 14, 2020 at 6:35 | history | answered | planetmaker | CC BY-SA 4.0 |