This is the mail archive of the
mailing list for the Cygwin project.
Re: RPM's require to much knowledge of setup to port easily
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
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 :)
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