Index of /~jalonso/www/cygwin-portage

      Name                    Last modified       Size  Description

[DIR] Parent Directory 26-Oct-2012 15:45 - [CMP] cygwin-overlay.tar.gz 02-Mar-2006 00:01 90k [TXT] make.conf 28-Feb-2006 20:22 1k [DIR] portage-overlay/ 28-Feb-2006 19:30 - [DIR] portage/ 02-Mar-2006 00:32 -

** ATTENTION **
There is now a wiki: http://gentoo-wiki.com/HOWTO_Gentoo_on_Cygwin
  As of 2006-0302-0033 (that is, 12:33 in the morning), the wiki contains a complete, working HOWTO.
** ATTENTION **


This is a disorganized collection of important notes and musings, though there is a peculiarly continuous stream of thought.  I strongly suggest that you read carefully.

It is possible to use Cygwin's managed-mounts feature to enforce case sensitivity and permit unusual characters in file names.

mount -o managed `cygpath -m /usr/managed/portage` /usr/portage

Packages that must be installed using Cygwin (since Windows does not support overwriting a program that is running) can be managed by putting entries in /etc/portage/profile/package.provided and /etc/portage/profile/virtuals.

- The "virtuals" file would contain entries like this:

  sys-libs/ncurses cygwin-binaries/ncurses

... This example allows the Cygwin ncurses package (as embodied by cygwin-binaries/ncurses) to satisfy ncurses dependencies.  More later on the origin of the cygwin-binaries category in portage.

- The "package.provided" file would contain entries like this:
cygwin-binaries/base-file-3.7a
cygwin-binaries/python-2.4.1-r1
cygwin-binaries/cygwin-1.5.19-r4
cygwin-binaries/ncurses-5.4-r4

... This would inform portage that these four packages are already installed.

Now, the problem is that we must fill this in with data.  Fortunately, it is theoretically possible to auto-generate this data (both package and version) using "cygcheck -c -d" and some sort of processing script.

The cygwin-binaries category of ebuilds (in a portage overlay) populated using a script that read a setup.ini file derived from a script of similar function.  I say "derived" because the original script did not produce ebuilds that portage accepted.

The biggest problem on this front is that the Cygwin versioning scheme, though simple and logical, does not fit portage naming standards.  To circumvent this, I believe the best solution would be to develop a script that remaps Cygwin version numbers to Gentoo version numbers, and it should be possible to overload the remapping algorithm on a per-package basis.

Some may be curious as to how I seem to have overlooked the problem of porting ebuilds.  The patches to portage are minor--if the sys-apps/portage folks over at Gentoo are kept aprised of what's needed, maintream portage will stay compatible.  Once that goes through (and the Cygwin arch is accepted), the lack of the Cygwin keyword everywhere else becomes a "bug", and the maintainers of each ebuild will happily accept patches.

Now I come full circle.  Typing "quickpkg sys-apps/portage" creates a tbz2-ball that can be fed into upset.