RE: missing file FOO.dll

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

> -----Original Message-----
> From: Jan Nieuwenhuizen [mailto:janneke@gnu.org] 
> Sent: Saturday, 1 June 2002 3:14 AM
> To: Robert Collins
> Cc: cygwin@cygwin.com
> Subject: Re: missing file FOO.dll
> 
> 
> "Robert Collins" <robert.collins@itdomain.com.au> writes:
> 
> > Do you provide a setup.ini fragment for merging into the 
> main setup.ini,
> > and just your tarballs, or do you provide cygwin1.dll etc etc?
> 
> I'm providing the minimal mirror of tarballs (cygwin-1.3.10, awk, ash,
> bash, fileutils, some lib*, etc.) that are needed from cygwin.com, my
> onw tarbals, and a generated setup.ini (generated from setup.hint
> files) for my partial distribution.  I'm trying to make sure that
> people can switch between my mirror and a full cygwin.com mirror, to
> install additional packages (Xfree, gcc, whatever).

With the multi-site capability in setup, they should be able to simply
have your site && a full cygwin mirror in setup.exe. Then you don't need
to carry any of the 'standard' packages, just your additional ones. All
you need in your setup.ini is the package data for your pacakges, and
the correct requires: lines.
 
> Which, btw, reminds
> me of the off-topic issue that I think maybe /etc/setup should be
> moved to /var, as it's not so much config settings rather than state.

Yes. Like the log files :}. It's a slow process to do this *right*. I've
got a plan.....
 
> > Reproducing that isn't that hard given the current state of
> > setup.exe's codebase.
> 
> Yes.  Setup has come a long way.  But still, doing it ourselves we'll
> have to play catchup and implement new stuff ourselves.  No easy way
> into apt-get (for .rpm or .deb), eg.

Yes there is. 
A) finish implementing the debian tags.
B) Add .deb file format support.
C) add the capability to read the database apt-get creates.
D) Add support to retrieve the Releases files from setup and create the
apt-get database outselves.

A has immediate benefits in terms of package management.
B allows the use of dpkg tools.
C allows the use of apt-get from the commandline in an interoperable
fashion.
D allows all-in-one support.

That's a pretty easy path, no challenges...just time.
 
> > It's a time issue though. And you've neglected
> > to cover the following issues for using dpkg/rpm to bootstrap:
> >
> > * native ports are needed.
> > * monolithic downloads are a must for the installer, thus requiring
> > static links to librarized versions of every tool that 
> dpkg/rpm need.
> > Non-trivial.. And setup has this already.
> 
> I'd think of setup.exe having a special bootstapping mode for first
> install: download and unpack base.tar.bz2.  Then, and always after
> that, using the package manager to do dependencies and stuff.  Only
> after untarring the base system, mounts would be reconfigured after
> the user's preference.

Yes, I've mused on this approach on cygwin-apps a few times :}. IMO it
boils down to a few key points:

1) We need a native, robust, in-use-handling, setup.exe compatible
dpkg/rpm. (By setup.exe compatible, either setup.exe understands it's
database, or vice verca).
2) Then we can test, test and test some more.
3) We can implement such a bootstrap system.

Anyway, these days I think that setup.exe's code base is so close to
allowing full console support that we'll not need direct ports, we'll be
able to implement to the spec instead.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/