Hi Simon, Thanks you very much for your comments and information. We are digesting it and will come back later on these
eric -----Original Message----- From: Simon Richter [mailto:s...@debian.org] Sent: Thursday, February 25, 2016 9:27 AM To: debian-devel@lists.debian.org; Eric Mittelette <ericm...@microsoft.com> Subject: Re: Debian package on Windows Hi, Eric Mittelette wrote: > I'm PM in the Visual C++ Team (VC Lib to be precise here at > Microsoft), we started to think about lib acquisition (still a painful > process for > C++ on Windows) and we are imaging different options, one is to port > apt-get on Windows. > Porting Apt-Get mean using Debian format (we love it) and providing > Windows binary inside the package... Heh. I like the MSI format (although it is a bit complex), because it manages to pull everything into a descriptive rather than imperative format, something I would've liked to see in dpkg for ages. I'm currently organizing my toolchain around MSIs and MSMs -- shared libraries exist as an MSM that installs the DLL along with the program, and the MSM is distributed along with the header and import library inside its own MSI, so in principle we could treat libraries in the same way the VC runtime is handled. The main difficulty in Windows is not so much the package format, but rather the ecosystem. There is no central repository of trusted libraries, because there are no curators, so every vendor must ship their own copies of everything, and keep them up to date. The App store cannot be used, because apps are heavily sandboxed, and I wouldn't trust anything from that place anyway. To share libraries between many projects, ABI tracking is needed (as the Unix world does with the SONAME numbering), and libraries with different ABI versions need to be concurrently installable. At the same time, a mechanism is needed to update older ABI versions if needed (e.g. OpenSSL and its many releases would definitely profit here). Within Debian, that is easy, because we can simply recompile everything that is linked against an old ABI, and even patch it if it fails to compile, but that is not a real option in the Windows ecosystem. Last but not least: The Windows ecosystem is easy in terms of licenses. In general, if you link against something, you also ship it, so there are very few debates on whether linking is allowed, because there are only system libraries, and libraries distributed with the app, and people generally read the licenses of libraries they ship, and make sure they have the necessary rights. In contrast, linking against a library that can be pulled in with a single dependency declaration sometimes even happens by accident as an indirect dependency, and create a situation where debian-legal needs to sort out whether the package is distributable at all. This is not an unsolvable problem, but it is something that the community needs to be prepared for. Putting my CI hat on: it is absolutely great to be able to install a library into the build environment without having it globally registered and available, so I can test different versions in parallel on the same machine. On Unix, this is easiest done with a chroot, so the "global" availability isn't actually global. On Windows, I install packages below the CI workspace, and point the current package build there. Any system that loses me the ability to isolate would be difficult to use. That said, it was a lot of work to set up the VC build for KiCad[1], and I would welcome anything to make this easier. I've started on a simple system that will make building MSI, MSM and MSP packages easier, but that is still focused at generating a single installation package, and possibly a few patch packages to ship incremental updates. Simon [1] http://ci.kicad-pcb.org/view/Windows/
