Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: <cygwin AT cygwin DOT com>
Subject: Re: missing file FOO.dll
References: <000f01c208bf$525df420$0200a8c0 AT lifelesswks>
Organization: Jan at Appel
From: Jan Nieuwenhuizen <janneke AT gnu DOT org>
Date: Fri, 31 May 2002 19:14:16 +0200
In-Reply-To: <000f01c208bf$525df420$0200a8c0@lifelesswks> ("Robert
 Collins"'s message of "Sat, 1 Jun 2002 02:22:12 +1000")
Message-ID: <87vg948ck7.fsf@peder.flower>
Lines: 88
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2
 (i386-debian-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Robert Collins" <robert DOT collins AT itdomain DOT com DOT 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).

> Can you get a setup.log + setup.log.full of a failed upgrade? That
> should help me pinpoint if setup is a culprit.

Yes, that's what I always ask for...

> Do you mean setup.ini? Setup.hint's are source files for upset, and not
> understood by setup.exe. 

Yes, but I'm still using a script that creates setup.ini from all the
hint files.  I should integrate the new upset and make it work with my
distribution, but I haven't found the time yet.

> Yup. IIRC you where going to put some time into that for
> setup.exe....

Yes, I asked around about that, because I thought it was needed for
the tetex setup.  But you convinced me not to rename any of the tetex
packages, and that while still nice to have, it wasn't a requirement.
There you go...

> Did you ever get time to do that? We also really need a provides: line
> and a versioned conflicts: line.

Yes, we should.  No, I haven't put any time into that, and there's
even less time coming up: LilyPond 1.6 is coming up, and today I got
the keys to my new house.

I've also said I wanted to look at different mount places for /etc and
/home during install, so that you could easily test fresh setups by
doing rm -rf /cygwin and not loose your setting.  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. Most importantly though, a node in the dependency tree changing
> should -not- require leaf nodes to be version bumped, unless it is not
> backward compatible. Our current lack of provides: gives rise to some
> potential problems, but fortunately we don't have versioned metadata, so
> we avoid them... For now.

Ok.
  
>> Hmm, that's why I have long (pre-setup.exe) wondered why Cygwin would
>> not adopt rpm (or dpkg, whichever)
>
> I have long lobbied for such approaches. However: I think that the
> greatest benefit in rpm/dpkg is not the actual package itself, but the
> support tools for maintainers, and the logic.

Agreed.

> 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.

> 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.

Jan.

-- 
Jan Nieuwenhuizen <janneke AT gnu DOT org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
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/