Hi list,I'd like some help filling in the blank: msys2 is to Windows as _____ is to Debian.
Is there anything in Debian that lets me have a user-land build environment? I want to install all my build dependencies in user-land, without being root, without disrupting my normal system. Once the package is built I want to move it to my normal Debian system and test it by installing/uninstalling as root.
Also, I want to build normal, boring deb packages, not containers or anything like that. Is there a way to do this?
-Jonathan
One thing-- msys2 might be the wrong analogy here, as there are some wrappers necessary to get it to work with native windows APIs. I'm just talking about the ease of installing a package, using it as a build environment without being root, and being sure it doesn't leave any state after I uninstall/reinstall that package. Thanks,Jonathan
On Wednesday, April 27, 2016 11:47 AM, Jonathan Wilkes <jancsika@yahoo.com> wrote:
Hi list,I'd like some help filling in the blank: msys2 is to Windows as _____ is to Debian.
Is there anything in Debian that lets me have a user-land build environment? I want to install all my build dependencies in user-land, without being root, without disrupting my normal system. Once the package is built I want to move it to my normal Debian system and test it by installing/uninstalling as root.
Also, I want to build normal, boring deb packages, not containers or anything like that. Is there a way to do this?
-Jonathan
On 04/27/2016 05:52 PM, Jonathan Wilkes via Pd-list wrote:
Also, I want to build normal, boring deb packages, not containers or anything like that.
TL;DR cannot help you much....
probably not exactly what you are looking for, but: i (and many other people at Debian) use gbp-buildpackage for building Debian packages (a frontend for pbuilder/schroot/...), which builds packages in a clean environment (that gets bootstrapped from scratch for each build).
apart from not interfering with the environment, this is also a good test whether the assumed build environment is sane (since (official) Debian packages are automatically build on a number of different architectures, this is a reasonable request).
this is accomplished with quite some overhead (basically an entire (minimal) system is re-installed for each build), and the way this is done is slower than on CI-services like travis-ci. otoh, the builds are done against a current Debian/unstable system (which changes daily) rather than some aged ubuntu/precise image (which hasn't changed in the last 4 years).
oh, and it just occured to me, that this requires sudo for each run :-(
so if you don't want to touch your precious baremetal environment, i'd suggest to fire up a virtual machine for development (VirtualBox, libvirt/KVM,...). personally, i'm using this for development of both kernel modules (where a bug usually requires a reboot, which is rather tiresome if it is the machine you are actually doing the work on) and for development on exotic OSs (BSD, Hurd, W32, OSY).
as for normal development targetted at Debian, i haven't experienced any problems so far with installing all that stuff on my day-to-day working environment (hey, i'm a dev; having those things available is part of my work): true, the development machine needs to install a lot of dev-packages which are unneeded on the deployment system, but those dev-packages mainly consist of headers...
gmfadsr IOhannes
One thing about msys2 that makes it a dream is that it's virtually guaranteed _not_ to be installed on a given Windows machine. So not only can I use it as a GNU toolchain, I can also use it as a build container without mucking up the system. I can descend on a Windows machine, set up camp, build Pd-l2ork, break everything down (i.e., uninstall it), and leave nothing but the Pd-l2ork package. The total process takes almost 1.5 hours total.
It takes quite a bit less time if I build Pd-l2ork on a Debian machine by installing all the dependencies and compiling directly in the OS. But I don't trust apt enough to configure and uninstall the build environment on an arbitrary machine. (Same with Ubuntu, etc.) Guix looks promising in this regard, but that kind of system looks to be a long way off from mainstream Linux distros. -Jonathan
On Wednesday, April 27, 2016 3:32 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 04/27/2016 05:52 PM, Jonathan Wilkes via Pd-list wrote:
Also, I want to build normal, boring deb packages, not containers or anything like that.
TL;DR cannot help you much....
probably not exactly what you are looking for, but: i (and many other people at Debian) use gbp-buildpackage for building Debian packages (a frontend for pbuilder/schroot/...), which builds packages in a clean environment (that gets bootstrapped from scratch for each build).
apart from not interfering with the environment, this is also a good test whether the assumed build environment is sane (since (official) Debian packages are automatically build on a number of different architectures, this is a reasonable request).
this is accomplished with quite some overhead (basically an entire (minimal) system is re-installed for each build), and the way this is done is slower than on CI-services like travis-ci. otoh, the builds are done against a current Debian/unstable system (which changes daily) rather than some aged ubuntu/precise image (which hasn't changed in the last 4 years).
oh, and it just occured to me, that this requires sudo for each run :-(
so if you don't want to touch your precious baremetal environment, i'd suggest to fire up a virtual machine for development (VirtualBox, libvirt/KVM,...). personally, i'm using this for development of both kernel modules (where a bug usually requires a reboot, which is rather tiresome if it is the machine you are actually doing the work on) and for development on exotic OSs (BSD, Hurd, W32, OSY).
as for normal development targetted at Debian, i haven't experienced any problems so far with installing all that stuff on my day-to-day working environment (hey, i'm a dev; having those things available is part of my work): true, the development machine needs to install a lot of dev-packages which are unneeded on the deployment system, but those dev-packages mainly consist of headers...
gmfadsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2016-04-28 02:31, Jonathan Wilkes via Pd-list wrote:
But I don't trust apt enough to configure and uninstall the build environment on an arbitrary machine.
i wonder why you don't trust it.
Debian uses a a number of (automated) tests to ensure well-behavedness of packages, including their complete uninstallability. checkout out [piuparts].
in any case, i'm not sure i understand the actual reasoning behind the request: it seems that you want to be able to easily build pd-l2ork on a number of different machines (where you only have limited access). may i ask why? the question seems to boil down to: why can't you build the deb on *your* machine (a dedicated development machine) and deploy the package on all the other machines? after all, we are talking about apt, not emerge...
if this is mainly about building for different architectures, you might want to have a look at [qemubuilder].
alternatively, you might want to think about getting Pd-l2ork into Debian proper. (that however would most likely mean that this package would need to use the externals already packaged for Debian (and build for pd-vanilla) instead of shipping your own copy; if you are still interested, contact me off-list)
fgmasdr IOhannes
[piuparts] https://piuparts.debian.org/ [qemubuilder] https://wiki.debian.org/qemubuilder
i wonder why you don't trust it.
Experience. Things can break, or get in a weird state. When they do it can be a real pain to fix. If I had to guess, I'd say the problem is that a) apt can't do transactional upgrades/rollbacks, b) the dependency tree for Pd-l2ork/Pd-extended is rather large, and c) it takes a bit of time to download/install that rather large dependency tree. I don't _need_ to be able to build on random machines. But setting up the build process to facilitate that actually lowers the cost (in human time) of building the software. Anyway, it sounds like the virtual machine approach is still the best approach for GNU/Linux distros.
On Thursday, April 28, 2016 3:39 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2016-04-28 02:31, Jonathan Wilkes via Pd-list wrote:
But I don't trust apt enough to configure and uninstall the build environment on an arbitrary machine.
i wonder why you don't trust it.
Debian uses a a number of (automated) tests to ensure well-behavedness of packages, including their complete uninstallability. checkout out [piuparts].
in any case, i'm not sure i understand the actual reasoning behind the request: it seems that you want to be able to easily build pd-l2ork on a number of different machines (where you only have limited access). may i ask why? the question seems to boil down to: why can't you build the deb on *your* machine (a dedicated development machine) and deploy the package on all the other machines? after all, we are talking about apt, not emerge...
if this is mainly about building for different architectures, you might want to have a look at [qemubuilder].
alternatively, you might want to think about getting Pd-l2ork into Debian proper. (that however would most likely mean that this package would need to use the externals already packaged for Debian (and build for pd-vanilla) instead of shipping your own copy; if you are still interested, contact me off-list)
fgmasdr IOhannes
[piuparts] https://piuparts.debian.org/ [qemubuilder] https://wiki.debian.org/qemubuilder
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes