Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002

[Alexey Pavlov <alexpux at gmail dot com>]

2014-12-10 19:01 GMT+03:00 Corinna Vinschen:
> On Dec 10 08:36, Alexey Pavlov wrote:
>> [...]
>> Our changes to Cygwin runtime as we talk in the past are not
>> acceptable to Cygwin upstream because have a different philosophy and
>> have break some posix features. About half a year ago we talk about
>> how integrate MSYS functionality into Cygwin upstream. As a result of
>> this discussion was added this code:
>> https://github.com/Alexpux/Cygwin/commit/4f756d6cc28179319ceccce01dd698de3f22c212
>> To try make MSYS functionality separate from original Cygwin DLL.
>>
>> But as our team is small and we have our real work too, we don't have
>> time and in some parts necessary knowledges to finish this work.
>
> As you may have noticed, our "team" is pretty small as well.  It looks
> a lot like it's smaller than yours.

Yeah, but you is paid to work full time on Cygwin. While for us this
is just free-time project.
Sometimes we don't do anything for couple of weeks just because of lack of time.
Only 2 persons work on MSYS2 itself and both are have many other work
then MSYS2.
For you Cygwin is target of work but for us MSYS2 is just a tool to do
other work.
So we need time-share between different works.

>
>> Also
>> I think some changes can't be easily separated into external dll.
>> So we open minded to incorporate with Cygwin if anyone will help with
>> finishing this work.
>
> The problem is not that your changes can or can't be implemented using
> cgf's suggested change, the problem is that you simply never discussed
> it.  Cgf started a discussion of what changes might be required on
> 2013-07-30:
>
>   https://cygwin.com/ml/cygwin-developers/2013-07/msg00075.html
>
> As you may have noticed, the mail explicitely mention that this was
> supposed to be a discussion.  He then checked in a preliminary patch to
> a branch:
>
>   https://cygwin.com/ml/cygwin-developers/2013-07/msg00076.html
>
> The result:  Nothing.  You could have heard the crickets chirping in the
> thread.  No.  Reply.  At.  All.  Until 2013-10-21, almost three months
> later, cgf asked if nobody is interested to pick up:
>
>   https://cygwin.com/ml/cygwin-developers/2013-10/msg00007.html
>
> Reply:  We're just busy.  Then... nothing.  Crickets again, the thread
> collecting dust and cobwebs.  Another four months later, cgf pinged you
> guys and the result:
>
>   https://cygwin.com/ml/cygwin-developers/2014-02/msg00001.html
>
> Then... nothing.
>
> How do you expect any progress if you don't at least **discuss what's
> necessary, and eventually code up and test changes?
>
So here we have lost time...
But there are good too - we drop old MSYS code in this months.

> Both of us definitely lost interest after Feb-2014, because, apparently
> you weren't able to come up with anything.  You have your solution,
> which is a bunch of patches, and that's apparently enough for you.
> There's no interest to follow up on a better solution, from what I see.
>
>> In contrast with Cygwin developers, we don't have any problems with
>> Arch Linux developers
>
> You don't have interoperability issues with Arch Linux.  I explained
> what we were thinking of pretty detailed on the mingw-w64-public mailing
> list.  Without going into much detail now, the idea would have been
> basically to keep the MSYS2 distro based on the latest Cygwin packages,
> and have the behavioral change hidden behind the MSYS2 hook.  You could
> have a seamless integration between all of the Cygwin distro and the few
> parts of the MSYS2 distro which really needed a patch.  Basically MSYS2
> could have been a subset or even an integral part of a Cygwin distro,
> which would have (probably) benefitted all of us.
>
We have very different structure than Cygwin. So in any case we will need
create our own distro as we don't want to use Cygwin build packages system
and installer. Pacman solve a lot of problems for maintaining packages.
Also we switch to use real /usr folder and just create virtual mount for /bin
folder that needed for some programs.

>> So if you want to "grab" or "rip-off" (as you wish) our pacman, feel
>> free to get it and use under Cygwin. We don't have any problems with
>> it.
>
> It's not really feasible because it requires to rebuild all packages.
> We're also relying on an infrastructure which is kind of bound to the
> setup and upset tools so far. Also, does pacman work without a basic
> MSYS2 installed already, or do you have to have an MSYS2 install
> to be able to run pacman?

Pacman is MSYS-like program not Windows native so it can be run only
from install.
Our installer give user minimal system from what he can use pacman to
install packages
that user need. Minimal system also created with pacman using "chroot"
and then archived for installer.
MSYS2 is rolling-release system so we really don't have versions -
just create installer for current "snapshot"
to give new users more recent system without installing tons of
updates. But users also can upgrade system to recent from older
installers too.

>
> If we could make pacman work with setup.ini, I wouldn't be unhappy
> to have this as an accompanying CLI tool for installing Cygwin packages.

Pacman will not work with Cygwin's setup.ini. It have it's own
database per repository
of packages. So you can have, for example, official repository and
some user's own repositories.
Also for pacman present some GUI's:
https://wiki.archlinux.org/index.php/Pacman_GUI_Frontends


>
> And if somebody thinks setup and the whole infrastructure is bad, all I
> can say is, maybe, but somebody has to have *time* and *volition* to
> implement something new.  Something still operating as a GUI installer
> to install a Cygwin distro from the ground up.  And also something on
> the server side to support the new layout.  And the packager support.
> As long as my reqeusts for volunteers goes unheard, I don't see how we
> could change that.
>
>
> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple