From: Lloeki <lloeki AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: RPM's require to much knowledge of setup to port easily
Date: Fri, 16 Jun 2006 10:13:44 +0200
User-Agent: KMail/1.9.1
References: <061020062022 DOT 10945 DOT 448B29F200067FE000002AC122068246930A050E040D0C079D0A AT comcast DOT net> <448DE34F DOT 6030303 AT cygwin DOT com> <449235C2 DOT 5030206 AT tlinx DOT org>
In-Reply-To: <449235C2.5030206@tlinx.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;   charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <200606161013.44695.lloeki@gmail.com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Friday 16 June 2006 06:38, Linda Walsh wrote:
> Larry Hall (Cygwin) wrote:
> > Ah, the lack of a Windows RPM port was *exactly* the reason
> > setup.exe was created.  The simplest way to port RPM was to use
> > Cygwin, which then leads to a chicken/egg problem.
>
> ----
>     Most linux distributions have solved this issue.  When one goes
> to do an install on a fresh system, there is no RPM on the target
> machine.  RPM usually doesn't run on the target machine for
> various reasons (no libs, no utils, no directory structure, no
> filesystem..etc.) :-)
Then, please install yourself a gentoo system, you'll get to know how almost 
all those nifty linux installers work. you'll see that even before beginning 
installation, you'll have all libs, utils and fs you wished for. Create 
harddisk fs and copy over a basic layout, then chroot into it, and start 
installing stuff with your favorite package manager. My point is, the package 
system cannot run under the not-yet-installed OS, but it could populate it 
just as well since there's an OS at hand, provided it has an option to 
install to a specific location/system, not the current one. that's overkill 
though, and "unpack, chroot, manage" is much more straightforward

>     I'm sure, but perhaps more interesting might be emails
> talking about when RPM might become an accepted way to distribute
> cygwin packages (not that there is anyone to work on it right now,
> but if there was).  It's not that RPM is a great work of art or
> necessarily even worthy of being a standard, but the point of
> cygwin is to provide an environment that makes it easier to
> port POSIX compatible (or *ixish) applications.  Using a
> widely adopted package standard like RPM would make the cygwin
> environment more application-porting friendly.

why rpm? why not deb ? why not ebuilds? I consider synaptic and portage to be 
much more efficient and designed in a much better way: rpm paved the way, but 
it's out now. that's my POV though.
anyway it might just be much more smart to use source-packaging rather than 
another specific bin-packaging format. building from source is much more 
profitable in terms of coverage because lots (but never enough) of source tgz 
just compile OOB under cygwin (i've built countless myself), thus just 
requiring an eclass. sure, building from source takes a long time (esp. under 
cygwin), but it requires close to zero work for package maintainers. and 
nothing forbids anyone to distribute gcc/glibc/whatever as binaries to save 
time. it also requires much less hosting from cygwin (just patches and 
ebuilds, plus some selected bin-pkg). 
and don't fool yourself, the user base of cygwin is rather small compared to 
any linux distro, and the package maintainer base is even smaller, and if 
people ever intended to package for cygwin, they would have made software 
that compiles against it (which is, albeit what I said earlier, often not the 
case, but is with some trivial patches). so the gain of switching to another  
bin-pkg format is close to nil. plus I believe building from source is the 
POSIXest way of doing things (one package fits all systems).

so my conclusions are: 
1. there's no significant gain to switch to another bin-pkg format
2. any real gain for a growing numper of packages would come from source-level 
support, not package support.
=> if a switch is ever to occur, it should be in favor of a source-pkg 
autobuild format (with bin-pkg support), to encourage source-level support.

surprisingly the thing exists, it's called cygport. I didn't test it but it 
seems a nice piece of software.

I would envision a future version of cygwin just similar to gentoo install 
procedure:
0. an install of the lower layer (for gentoo, it's a bootcd+fs creation, for 
cygwin it's a windows installation)
1. a first stage setup that fetches and un-tgz a very basic layout (like a 
gentoo stage3 tarball), and sets up basic things. at the end of this stage we 
would have a working (albeit crude) cygwin system.
2. a second stage package manager frontend, popped up by the first stage setup 
to install more packages. this tool is the one available afterwards to manage 
packages, and offers both the frontend and the cli.

The current cygwin setup.exe just does both 1 and 2 at once. it can because 
it's not an OS but a layer, and so does not need things like chroot 
after "duplicating" itself to another media, so setup relies ony on windows 
to do its work. IMHO steps 1 and 2 should be separated. after all, setup is 
unable to uninstall cygwin, and it's not like it's wise to change things like 
line endings or "install for current/all users" once installed, so what's the 
point of keeping 1 in the package manager? plus I think it might be a good 
idea to have the second stage being a "pure cygwin" app which is impossible 
if keeping 1 and 2 together.

FWIW, IJKCGASM and just won't listen to my unending source of truth :)

lloeki

ps: as you all guessed, I'm running a gentoo system :p

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