Re: Debian package on Windows

[Paul Wise]

On Thu, Mar 31, 2016 at 7:39 PM, Paul Wise wrote:

> I seem to remember some more tech info is in the HN thread:
>
> https://news.ycombinator.com/item?id=11390545

Actually it was this one:

https://news.ycombinator.com/item?id=11388418

Re fork, they implemented that in the Windows kernel and exposed that:

https://news.ycombinator.com/item?id=11391797

Not sure about the rest.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian package on Windows

[Paul Wise]

On Thu, Mar 31, 2016 at 5:54 PM, Steve McIntyre wrote:

> As I commented on Dustin's blog, I'm also interested in more technical
> details:

I seem to remember some more tech info is in the HN thread:

https://news.ycombinator.com/item?id=11390545

> Some Linux programs will be easy to support, some - say, dpkg, are
> going to be much more involved.

Sounds like apt/dpkg are already supported.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian package on Windows

[Simon Dann]

>
> Linux/Unix is more than just the syscalls, there's quite a few places
> where the Windows model just doesn't match up with the Unix model:
> processes, threads, filesystem/VFS semantics, ...
>
> How does fork() work?  How does file locking work with things like
> shared libraries in this setup?
>

I'd like to think that its a good step in an interesting direction. They
did show using apt-get to install packages so I do wonder how much they
still need to do?

Re: Debian package on Windows

[Steve McIntyre]

z...@debian.org wrote:
>On Thu, Mar 31, 2016 at 03:03:18PM +0800, Paul Wise wrote:
>> Quite ingenious really.
>
>I'm curious about the set of syscalls they've implemented, and in
>particular about which non-POSIX (but Linux) syscalls are in that set.
>Has anyone seen that list yet?

As I commented on Dustin's blog, I'm also interested in more technical
details:

Linux/Unix is more than just the syscalls, there's quite a few places
where the Windows model just doesn't match up with the Unix model:
processes, threads, filesystem/VFS semantics, ...

How does fork() work?  How does file locking work with things like
shared libraries in this setup?

Some Linux programs will be easy to support, some - say, dpkg, are
going to be much more involved.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Re: Debian package on Windows

[Marco d'Itri]

On Mar 31, Stefano Zacchiroli  wrote:

> I think we should. It will help Windows users use less proprietary
> software in their daily lives, and my very well work as a "gateway drug"
> to 100% Free Software in the long run.
Agreed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Debian package on Windows

[Stefano Zacchiroli]

On Thu, Mar 31, 2016 at 03:03:18PM +0800, Paul Wise wrote:
> Quite ingenious really.

I'm curious about the set of syscalls they've implemented, and in
particular about which non-POSIX (but Linux) syscalls are in that set.
Has anyone seen that list yet?

> I wonder if we should start offering Debian installs for it too, as we
> do for other non-free hardware/virtualisation/cloud platforms.

I think we should. It will help Windows users use less proprietary
software in their daily lives, and my very well work as a "gateway drug"
to 100% Free Software in the long run.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Debian package on Windows

[Paul Wise]

On Thu, Mar 31, 2016 at 2:56 PM, Johannes Schauer wrote:

> This solution does not need to reimplement any library functions, as they can
> take everything from the unpacked Ubuntu rootfs and then "just" need to handle
> the Linux systemcalls correctly.

Quite ingenious really. I wonder if we should start offering Debian
installs for it too, as we do for other non-free
hardware/virtualisation/cloud platforms.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian package on Windows

[Johannes Schauer]

Quoting Paul Wise (2016-03-31 08:42:58)
> On Thu, Mar 31, 2016 at 2:38 PM, Johannes Schauer wrote:
> > It looks mightily impressive! When I read about this originally I didn't
> > find a link with so many details and even screenshots - thanks for that! It
> > seems they can even run apt (and thus dpkg) with this "reversed wine" :D
> 
> Seems like it is fairly different to Wine, more like the BSDs' Linux
> syscall emulation layers or qemu-user's cross-arch syscall translation.

you are right. Calling it a "reversed wine" doesn't do the wine project enough
justice who had to reimplement tons of windows libraries from scratch and
without being able to see the source ever.

This solution does not need to reimplement any library functions, as they can
take everything from the unpacked Ubuntu rootfs and then "just" need to handle
the Linux systemcalls correctly.

cheers, josch


signature.asc
Description: signature

Re: Debian package on Windows

[Paul Wise]

On Thu, Mar 31, 2016 at 2:38 PM, Johannes Schauer wrote:

> It looks mightily impressive! When I read about this originally I didn't find 
> a
> link with so many details and even screenshots - thanks for that! It seems 
> they
> can even run apt (and thus dpkg) with this "reversed wine" :D

Seems like it is fairly different to Wine, more like the BSDs' Linux
syscall emulation layers or qemu-user's cross-arch syscall
translation.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian package on Windows

[Johannes Schauer]

Quoting Paul Wise (2016-03-30 19:52:51)
> Looks like Microsoft went with a Linux syscall emulation layer for the
> Windows kernel:
>
> http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html

if I understand it correctly, then this should indeed solve Eric's original
message.

It looks mightily impressive! When I read about this originally I didn't find a
link with so many details and even screenshots - thanks for that! It seems they
can even run apt (and thus dpkg) with this "reversed wine" :D

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Debian package on Windows

[Martinx - ジェームズ]

On 30 March 2016 at 14:52, Paul Wise  wrote:

> On Mon, Feb 22, 2016 at 10:05 PM, Jonathan Dowland wrote:
>
> > I think your message would be better addressed to the debian-devel
> mailing
> > list, who I have copied in to this reply so that more Debian Developers
> are
> > aware of it.  (There's also the Apt developer's mailing list at the
> > harder-to-discover de...@lists.debian.org who I have not copied in, as
> they are
> > likely all on -devel anyway)
> >
> > Personally (although I am not an Apt developer) I think it sounds like an
> > interesting idea, and there is some precedent as APT was the basis of the
> > "Fink" package management system for Apple Mac OS X.  Not re-inventing
> the
> > wheel is a very good idea, lots of package management problems have been
> > discovered and solved with APT already (and it's sad to see things like
> Ruby
> > gems, Go packages etc. re-discover the very same problems over and over
> again)
>
> Looks like Microsoft went with a Linux syscall emulation layer for the
> Windows kernel:
>
> http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
>
Something like this:

http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubuntu-to-windows-10/

Sounds super cool! Finally the "year of Linux on Desktop"!   lol

I would like to play with this, for sure...

:-D

Re: Debian package on Windows

[Jeffrey Walton]

On Wed, Mar 30, 2016 at 1:52 PM, Paul Wise  wrote:
> On Mon, Feb 22, 2016 at 10:05 PM, Jonathan Dowland wrote:
>
>> I think your message would be better addressed to the debian-devel mailing
>> list, who I have copied in to this reply so that more Debian Developers are
>> aware of it.  (There's also the Apt developer's mailing list at the
>> harder-to-discover de...@lists.debian.org who I have not copied in, as they 
>> are
>> likely all on -devel anyway)
>>
>> Personally (although I am not an Apt developer) I think it sounds like an
>> interesting idea, and there is some precedent as APT was the basis of the
>> "Fink" package management system for Apple Mac OS X.  Not re-inventing the
>> wheel is a very good idea, lots of package management problems have been
>> discovered and solved with APT already (and it's sad to see things like Ruby
>> gems, Go packages etc. re-discover the very same problems over and over 
>> again)
>
> Looks like Microsoft went with a Linux syscall emulation layer for the
> Windows kernel:
>
> http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html

Maybe worth mentioning... Some Microsoft tools use NuGet
(https://www.nuget.org/). Visual Studio uses it for its
developer-to-developer gallery of widgets and gadgets.

I don't think Microsoft will ever support a first class package
manager. They are trying to achieve exclusivity and vendor lock-in
through their app store, and a general package manager violates the
corporate goals.

Jeff

Re: Debian package on Windows

[Paul Wise]

On Mon, Feb 22, 2016 at 10:05 PM, Jonathan Dowland wrote:

> I think your message would be better addressed to the debian-devel mailing
> list, who I have copied in to this reply so that more Debian Developers are
> aware of it.  (There's also the Apt developer's mailing list at the
> harder-to-discover de...@lists.debian.org who I have not copied in, as they 
> are
> likely all on -devel anyway)
>
> Personally (although I am not an Apt developer) I think it sounds like an
> interesting idea, and there is some precedent as APT was the basis of the
> "Fink" package management system for Apple Mac OS X.  Not re-inventing the
> wheel is a very good idea, lots of package management problems have been
> discovered and solved with APT already (and it's sad to see things like Ruby
> gems, Go packages etc. re-discover the very same problems over and over again)

Looks like Microsoft went with a Linux syscall emulation layer for the
Windows kernel:

http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

RE: RE: Debian package on Windows

[Eric Mittelette]

Thanks Fabian, that make sense, we also having a look at this

eric

-Original Message-
From: Fabian Greffrath [mailto:fab...@debian.org] 
Sent: Monday, February 29, 2016 8:46 AM
To: Eric Mittelette <ericm...@microsoft.com>
Cc: debian-devel@lists.debian.org
Subject: Re: RE: Debian package on Windows

Hi there,

for my occasional development on Windows I use Msys2 which have Arch's pacman 
package management system ported to Windows and even provide a huge repository 
of pre-compiled package. It's not APT, but at least a reasonable packaging 
system and a bash shell on Windows to begin with.
;)

Best regards,

 - Fabian

Re: RE: Debian package on Windows

[Fabian Greffrath]

Hi there,

for my occasional development on Windows I use Msys2 which have Arch's
pacman package management system ported to Windows and even provide a
huge repository of pre-compiled package. It's not APT, but at least a
reasonable packaging system and a bash shell on Windows to begin with.
;)

Best regards,

 - Fabian


signature.asc
Description: This is a digitally signed message part

Re: Re: Debian package on Windows

[igor80]

> I could be useful to create a Debian GNU/ReactOS port to avoid the
> proprietary software dependency of a cross-compiled-only port.

Really? Wow!

--
igor

RE: Debian package on Windows

[Eric Mittelette]

Thanks you for your response, much appreciated
Very useful information we are going to digest...

eric

From: Josh Max [mailto:joshu...@hotmail.com]
Sent: Monday, February 22, 2016 11:38 AM
To: debian-devel@lists.debian.org
Cc: Eric Mittelette <ericm...@microsoft.com>; j...@debian.org
Subject: RE: Debian package on Windows

IIRC, windowspackager.org created wpkg, which allows for the installation of 
format 2.0 debs on Windows (Of course, they're meant to contain Win32 
binaries), It didn't really catch on though due to the nature of the design of 
Windows which made it a lot less feesable to integrate a package manager like 
dpkg into it (i.e. the registry, WoW subsystem, etc) and the fact that the 
Windows Installer Service handles a lot of these things already, albeit with a 
different form of functionality than dpkg and apt. -- Josh Max E657 F54A 65F5 
A6A2 > Date: Mon, 22 Feb 2016 14:05:33 + > From: 
j...@debian.org<mailto:j...@debian.org> > To: 
debian-devel@lists.debian.org<mailto:debian-devel@lists.debian.org> > CC: 
ericm...@microsoft.com<mailto:ericm...@microsoft.com>; 
debian-apa...@lists.debian.org<mailto:debian-apa...@lists.debian.org> > 
Subject: Re: Debian package on Windows > > [ for -devel: this is a reply to a 
post to debian-apache, please see > 
https://lists.debian.org/debian-apache/2016/02/msg4.html ] > > Hi Eric, > > 
I think your message would be better addressed to the debian-devel mailing > 
list, who I have copied in to this reply so that more Debian Developers are > 
aware of it. (There's also the Apt developer's mailing list at the > 
harder-to-discover de...@lists.debian.org<mailto:de...@lists.debian.org> who I 
have not copied in, as they are > likely all on -devel anyway) > > Personally 
(although I am not an Apt developer) I think it sounds like an > interesting 
idea, and there is some precedent as APT was the basis of the > "Fink" package 
management system for Apple Mac OS X. Not re-inventing the > wheel is a very 
good idea, lots of package management problems have been > discovered and 
solved with APT already (and it's sad to see things like Ruby > gems, Go 
packages etc. re-discover the very same problems over and over again) > > > -- 
> Jonathan Dowland >

RE: Debian package on Windows

[Eric Mittelette]

Thanks you very much for your response, that make sense... let us refine our 
thinking on that
Keep you posted

eric

-Original Message-
From: paul.is.w...@gmail.com [mailto:paul.is.w...@gmail.com] On Behalf Of Paul 
Wise
Sent: Thursday, February 25, 2016 4:20 AM
To: debian-devel@lists.debian.org; Eric Mittelette <ericm...@microsoft.com>
Subject: Re: Debian package on Windows

On Thu, Feb 25, 2016 at 6:37 PM, Guillem Jover wrote:

> I think people in general have concluded that such a port would be 
> mostly useful only to cross-build, but not to run stuff.

I could be useful to create a Debian GNU/ReactOS port to avoid the proprietary 
software dependency of a cross-compiled-only port.

--
bye,
pabs

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwiki.debian.org%2fPaulWise=01%7c01%7cericmitt%40microsoft.com%7c85e75a2ac7b24ef8d6f408d33dde0379%7c72f988bf86f141af91ab2d7cd011db47%7c1=zZAv5IYybGI4AaQAT35H1CzQ1VAEAj36BHQP%2fiFt7hM%3d

RE: Debian package on Windows

[Eric Mittelette]

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/

Re: Debian package on Windows

[Simon Richter]

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/



signature.asc
Description: OpenPGP digital signature

Re: Debian package on Windows

[Paul Wise]

On Thu, Feb 25, 2016 at 6:37 PM, Guillem Jover wrote:

> I think people in general have concluded that such a port would be mostly
> useful only to cross-build, but not to run stuff.

I could be useful to create a Debian GNU/ReactOS port to avoid the
proprietary software dependency of a cross-compiled-only port.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian package on Windows

[Guillem Jover]

Hi!

On Mon, 2016-02-22 at 14:05:33 +, Jonathan Dowland wrote:
> [ for -devel: this is a reply to a post to debian-apache, please see
>   https://lists.debian.org/debian-apache/2016/02/msg4.html ]

Inlining parts of that mail here:

> On Sat, 20 Feb 2016 01:09:18 +, Eric Mittelette wrote:
> > I contact you today about a crazy idea, but I hope it is a right kind of
> > crazy!

I have no problem with crazy, this one seems to me more shocking than
anything else. :)

> > 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.

I'd assume that porting apt itself should be not too difficult. As
Jonathan has pointed out, you might want to get in contact with the
apt team though.

  

> > Porting Apt-Get mean using Debian format (we love it) and providing
> > Windows binary inside the package...

If by that you mean you'd also want to use dpkg, then that might be a
bit more difficult, as dpkg relies heavily on the underlying system to
provide POSIX semantics. Such as being able to remove opened files, or
replacing opened files with other opened files. Extensive use of fork(2).
And other similar things.

I'd be quite uncomfortable working around several of those things to
make dpkg work on such a best though. Because some of those are IMO
the basis for a sane package manager.

  

> > For doing that we imagine a light way process to adapt your actual build
> > script to generate Windows binaries using our latest Clang/c2 compiler
> > integration (meaning in theory just changing an env variable to switch
> > from gcc or Clang to our Clang/C2 compiler will be enough...)

Over the years there's been attempts to create various Windows ports
based on different runtimes:

  Debian GNU/Interix
  
  

Hmm it seems we even have a mailing list, which seems pretty dead to me,
but might give background information on previous attempts:

  

I think people in general have concluded that such a port would be mostly
useful only to cross-build, but not to run stuff.

There are other teams that have worked to use clang instead of gcc in
Debian proper:

  

> > The main idea here is to not reinvent the wheel for packaging management
> > and use something existing, powerful and well known by the community.
> >
> > Of course all the project will be open source (the new Microsoft J)

That sounds great. And it would be an interesting curiosity to end up
adding this "thing" to . :)

> > Do you want to be included in future discussions and provide feedback as
> > we get more details fleshed out?

I'm not sure if there's interest in a Windows port of Debian, but
porting specific projects might be of interest to the particular
teams, so you'd want to contact those individually perhaps.

Also if you'd like for any changes you end up doing to be included in
the original projects, I'd recommend including those upstream teams in
your discussions, so that they can tell you what is and what is not
acceptable, or a direction they'll agree to take or not.

Thanks,
Guillem

RE: Debian package on Windows

[Josh Max]

IIRC, windowspackager.org created wpkg, which allows for the installation
of format 2.0 debs on Windows (Of course, they're meant to contain Win32 
binaries),
It didn't really catch on though due to the nature of the design of Windows 
which made
it a lot less feesable to integrate a package manager like dpkg into it (i.e. 
the registry,
WoW subsystem, etc) and the fact that the Windows Installer Service handles
a lot of these things already, albeit with a different form of functionality 
than dpkg and apt.

--
Josh Max
E657 F54A 65F5 A6A2

> Date: Mon, 22 Feb 2016 14:05:33 +
> From: j...@debian.org
> To: debian-devel@lists.debian.org
> CC: ericm...@microsoft.com; debian-apa...@lists.debian.org
> Subject: Re: Debian package on Windows
> 
> [ for -devel: this is a reply to a post to debian-apache, please see
> https://lists.debian.org/debian-apache/2016/02/msg4.html ]
> 
> Hi Eric,
> 
> I think your message would be better addressed to the debian-devel mailing
> list, who I have copied in to this reply so that more Debian Developers are
> aware of it. (There's also the Apt developer's mailing list at the
> harder-to-discover de...@lists.debian.org who I have not copied in, as they 
> are
> likely all on -devel anyway)
> 
> Personally (although I am not an Apt developer) I think it sounds like an
> interesting idea, and there is some precedent as APT was the basis of the
> "Fink" package management system for Apple Mac OS X. Not re-inventing the
> wheel is a very good idea, lots of package management problems have been
> discovered and solved with APT already (and it's sad to see things like Ruby
> gems, Go packages etc. re-discover the very same problems over and over again)
> 
> 
> -- 
> Jonathan Dowland
> 
  

Re: Debian package on Windows

[Jonathan Dowland]

[ for -devel: this is a reply to a post to debian-apache, please see
  https://lists.debian.org/debian-apache/2016/02/msg4.html ]

Hi Eric,

I think your message would be better addressed to the debian-devel mailing
list, who I have copied in to this reply so that more Debian Developers are
aware of it.  (There's also the Apt developer's mailing list at the
harder-to-discover de...@lists.debian.org who I have not copied in, as they are
likely all on -devel anyway)

Personally (although I am not an Apt developer) I think it sounds like an
interesting idea, and there is some precedent as APT was the basis of the
"Fink" package management system for Apple Mac OS X.  Not re-inventing the
wheel is a very good idea, lots of package management problems have been
discovered and solved with APT already (and it's sad to see things like Ruby
gems, Go packages etc. re-discover the very same problems over and over again)


-- 
Jonathan Dowland