Stating officially with Cygwin
 

Hello foks,

by end of this week I will have a script ready and tested, that can
bootstrap me the basical system on Cygwin. Then I can start with
nightly builds of Prefix on Cygwin.

A working bootstrapping path is documented by now on
http://en.gentoo-wiki.com/wiki/Prefix/Cygwin. Future experience will
show, how this can be reduced to the really necessary.

What are the next steps required to implement the Cygwin system
officially into Gentoo Prefix?

Thanks

Al

Stating officially with Cygwin
 

On Thu, 30 Sep 2010 16:43:40 +0200, Al <oss.elmar@googlemail.com>
wrote:

Hello foks,



<snip>


Your work effort is appreciated!


What are the next steps required to implement the Cygwin system
officially into Gentoo Prefix?


Past experience has left me jaded against adding support for more
platforms. Unless there are >1 highly *motivated* devs willing to work
with other Gentoo devs and other upstreams, I'd prefer that we didn't
add the platform's keywords/patches/etc. Normally what happens is that
more work gets "dumped" on the current Prefix developers in our efforts
to migrate packages back to Gentoo Linux and upstream. I, personally,
added unofficial support for ~arm-linux to the tree but didn't add any
keywords back in Jan 2010.


A small case study:
~x86-interix support, "currently broken" quote from the lead dev. Not
likely to get fixed soon. Causes headaches when trying to migrate
packages to Gentoo Linux.

~x86-winnt, worse than interix.
~m68k-mint, semi-supported by power user. Often patches are accepted
upstream and we don't see them (except for toolchain).
~irix-mips, power user..many bugs in bugzilla, not supported in
tree..no devs have access or desire.


How to go forward:
- I suggest that you maintain your own overlay on an external site. We
can add your overlay to layman's configuration. This will allow you to
work independantly of us and will allow your platform to mature before
devs accept it. I think this is the best compromise for all parties
involved. If you don't need any patches then you don't need an overlay
and can simply add another keywrod to your ACCEPT_KEYWORDS variable.


-Jeremy

Stating officially with Cygwin
 

> How to go forward:
> - I suggest that you maintain your own overlay on an external site. We can
> add your overlay to layman's configuration. This will allow you to work
> independantly of us and will allow your platform to mature before devs
> accept it. I think this is the best compromise for all parties involved. If
> you don't need any patches then you don't need an overlay and can simply add
> another keywrod to your ACCEPT_KEYWORDS variable.
>
> -Jeremy

Hello Jeremy,

there is nothing wrong in this for me. The only thing I am afraid of
is, to be accused to provide a fork of Prefix, if I start hosting
things on extern servers. That is not my intend.

I also hope that more people join in, once things become usefull for
them. Most people don't become interested in a matter for mere
exercise or their brain. That requires, that I need to host some kind
of usefull products based on Prefix.

The other thing is, that I want to get some fixes into portage/eselect
sources. The typical problem is, that things break, where a path
evaluates to start with a double slash. While on Linux that doesn't
makes a difference on Cygwin it does.

Al

Stating officially with Cygwin
 

On Thu, 30 Sep 2010 18:50:06 +0200, Al <oss.elmar@googlemail.com>
wrote:

How to go forward:
- I suggest that you maintain your own overlay on an external site.
We can
add your overlay to layman's configuration. This will allow you to
work
independantly of us and will allow your platform to mature before
devs
accept it. I think this is the best compromise for all parties
involved. If
you don't need any patches then you don't need an overlay and can
simply add

another keywrod to your ACCEPT_KEYWORDS variable.

-Jeremy


Hello Jeremy,

there is nothing wrong in this for me. The only thing I am afraid of
is, to be accused to provide a fork of Prefix, if I start hosting
things on extern servers. That is not my intend.

I also hope that more people join in, once things become usefull for
them. Most people don't become interested in a matter for mere
exercise or their brain. That requires, that I need to host some kind
of usefull products based on Prefix.

The other thing is, that I want to get some fixes into
portage/eselect

sources. The typical problem is, that things break, where a path
evaluates to start with a double slash. While on Linux that doesn't
makes a difference on Cygwin it does.

Al


Well, it is not a true fork if you are working with upstream to get
your patches in. Then it is just a staging ground. Just like the Gentoo
Prefix "svn tree" is a staging ground for Gentoo Linux, eventually they
become one (in theory).


The workflow is something like:
-Take sys-apps/portage from Gentoo Prefix and put it in your overlay
-Work on patch in your overlay (your sandbox).
-Once patch is working, submit it to dev-portage (mainline) if possible
and then it trickles down into Gentoo Prefix's version.
-Remove sys-apps/portage from your overlay and rely on it being in the
Gentoo Prefix tree now that it needs no patches.


Same for other apps, including other upstreams that are not Gentoo.
With this plan, the major bottleneck is you so you get to decide how
fast you are going to work on issues. Otherwise, the Gentoo Prefix devs
(myself incl) are your bottleneck and you can see that we don't need
more stuff to do (230 open bugs, maintaining tree, migrating packages,
etc)


-Jeremy

Stating officially with Cygwin
 

> Same for other apps, including other upstreams that are not Gentoo. With
> this plan, the major bottleneck is you so you get to decide how fast you are
> going to work on issues. Otherwise, the Gentoo Prefix devs (myself incl) are
> your bottleneck and you can see that we don't need more stuff to do (230
> open bugs, maintaining tree, migrating packages, etc)

It is indeed one of the ingenious things in Gentoo, that you have a
full system to manage your personal overlay (distribution). You don't
depend on upstream developers as the bottleneck. By this more people
can learn how to work with patches and can emerge themself to future
upstream devs.

So where do you suggest to store the Cygwin distro? Is sourceforge
still a good choice today?

Al

Stating officially with Cygwin
 

On 30-09-2010 19:48:53 +0200, Al wrote:
> > Same for other apps, including other upstreams that are not Gentoo. With
> > this plan, the major bottleneck is you so you get to decide how fast you are
> > going to work on issues. Otherwise, the Gentoo Prefix devs (myself incl) are
> > your bottleneck and you can see that we don't need more stuff to do (230
> > open bugs, maintaining tree, migrating packages, etc)
>
> It is indeed one of the ingenious things in Gentoo, that you have a
> full system to manage your personal overlay (distribution). You don't
> depend on upstream developers as the bottleneck. By this more people
> can learn how to work with patches and can emerge themself to future
> upstream devs.
>
> So where do you suggest to store the Cygwin distro? Is sourceforge
> still a good choice today?

Depends more on what you like to use.
Repoman understands 'cvs', 'svn', 'git', 'bzr' and 'hg'.
emerge --sync understands 'rsync', 'cvs', 'svn' and 'git'.

The latter is not necessarily a bottleneck, since a simple $VCS update
will do too.


--
Fabian Groffen
Gentoo on a different level

Stating officially with Cygwin
 

>
> Depends more on what you like to use.
> Repoman understands 'cvs', 'svn', 'git', 'bzr' and 'hg'.
> emerge --sync understands 'rsync', 'cvs', 'svn' and 'git'.
>

Isn't there a kind of de facto standard for Gentoo? If not, I would go
with SVN. I know how to use it and there are reasons why it has
replaced CVS. Before I start learning GIT or BZR I'd like to see,
which one of the three becomes the standard. Don't need the exchange
my VCS knowlege every three years.

Al

Stating officially with Cygwin
 

On 30-09-2010 20:25:25 +0200, Al wrote:
> > Depends more on what you like to use.
> > Repoman understands 'cvs', 'svn', 'git', 'bzr' and 'hg'.
> > emerge --sync understands 'rsync', 'cvs', 'svn' and 'git'.
>
> Isn't there a kind of de facto standard for Gentoo? If not, I would go
> with SVN. I know how to use it and there are reasons why it has
> replaced CVS. Before I start learning GIT or BZR I'd like to see,
> which one of the three becomes the standard. Don't need the exchange
> my VCS knowlege every three years.

then don't make it any harder for yourself, and go for svn


--
Fabian Groffen
Gentoo on a different level

Stating officially with Cygwin
 

> A small case study:
> ~x86-interix support, "currently broken" quote from the lead dev. Not likely
> to get fixed soon. Causes headaches when trying to migrate packages to
> Gentoo Linux.

I wonder what is wrong with interix as it is that similar to Cygwin.
There are two points that come into my mind:

1.) Why do QA-warnings in misc-functions.sh kill emerges?

I have to disable thi line, that makes it all die. Else every third
package would break. In my understanding a warning is a warning and no
reason to become a blocker. Do I understand something wrong there? Do
I maybe still use an outdated script?

2.) gen_usr_ldscript() in toolchain-funcs.eclass

# @FUNCTION: gen_usr_ldscript
# @USAGE: [-a] <list of libs to create linker scripts for>
# @DESCRIPTION:
# This function generate linker scripts in /usr/lib for dynamic
# libs in /lib. This is to fix linking problems when you have
# the .so in /lib, and the .a in /usr/lib. What happens is that
# in some cases when linking dynamic, the .a in /usr/lib is used
# instead of the .so in /lib due to gcc/libtool tweaking ld's
# library search path. This causes many builds to fail.
# See bug #4411 for more info.

This functions creates symlinks to fix the order in which dynamic
libraries are found with a realtion to libtool. The curious thing is,
that this mechanism doesn't exist on windows. Windows simply uses
$PATH to find the dynamic libraries. Nonetheless, there is code in
this function for interix and winnt.

Is this a mere mistake or is the function highjacked to do something
slightly different in the case of Interix. I would consider to simply
return at the beginnig of the function for windows stuff.

Al

Stating officially with Cygwin
 

On 09/30/2010 09:04 PM, Al wrote:
>> A small case study:
>> ~x86-interix support, "currently broken" quote from the lead dev. Not likely
>> to get fixed soon. Causes headaches when trying to migrate packages to
>> Gentoo Linux.
>
> I wonder what is wrong with interix as it is that similar to Cygwin.
> There are two points that come into my mind:
>
> 1.) Why do QA-warnings in misc-functions.sh kill emerges?
>
[snip]

on interix, a missing or wrong interpreter is not handled correctly, and
thus leads to crashes without appropriate error messages. i'm really
glad portage now checks for those ;)

>
> 2.) gen_usr_ldscript() in toolchain-funcs.eclass
>
[snip]

interix is more like a real unix than cygwin; it uses symlinks, etc.
also, it does _not_ use PATH to search for libraries, but has propper
support for rpath, etc.

additionally the x86-winnt profiles, which i started, use the parity
compiler for windows [1], which adds support for rpath, lazy loading,
unix like shared library building, libtool support, etc, etc. so even on
windows, there is not need for PATH hacks, and such.

@jeremy: read your previous mail; yes i know, the interix stuff is
actually rather unmaintained at the moment. but i plan to change this. i
want to get things back to a working state the latest by January next
year (i hope i'll succeed ;)). in the meantime - don't pay attention to
interix. if patches/keywords disturb you, feel free to remove them -
I'll add them back in the version(s) I'll test in the course of
"resurrection" :)

[1] http://www.sf.net/projects/parity

P.S.: i built cygwin support into parity - would be curious if (after i
fixed the portage prefix-chaining patch, which is a prerequisite)
x86-winnt profiles would work unmodified on cygwin.

markus

>
> Al
>