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
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "'Jan Nieuwenhuizen'" <janneke AT gnu DOT org>, <cygwin AT cygwin DOT com>
Subject: RE: missing file FOO.dll
Date: Sat, 1 Jun 2002 02:22:12 +1000
Message-ID: <000f01c208bf$525df420$0200a8c0@lifelesswks>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <874rgo9uha.fsf@peder.flower>


> -----Original Message-----
> From: cygwin-owner AT cygwin DOT com 
> [mailto:cygwin-owner AT cygwin DOT com] On Behalf Of Jan Nieuwenhuizen

> > Because you manually screwed something up.
> 
> I don't understand.

Chuck is saying that something that setup is unaware of requries the
missing file(s).
 
> I'm maintaining a partial mirror of Cygwin, and offer additionally
> Guile and LilyPond.  When Guile (1.6?) is ready, it will hopefully get
> into Cygwin.  I'm not sure if lilypond ever will, but the separate
> repository we have now is not a grand solution either.  The setup.ini
> is generated using the original setup.hints from (a mirror of)
> cygwin.com.

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?
 
> When I'm doing test installations from scratch, it just works, and I
> don't have any missing dependencies.  But somehow, it seems that
> people that are upgrading, and maybe have an other/older version of
> cygwin installed, miss out on some dependency.

Can you get a setup.log + setup.log.full of a failed upgrade? That
should help me pinpoint if setup is a culprit.
 
> I want it to work, and if all setup.hints are correct, it should work.

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

> If not, I'd much rather bother the maintainer of a package, than tell
> a user to resolve dependencies by hand.  

Agreed.


> > So as long as "other sites" porovide programs that run on the cygwin
> > platform, we'll get these questions...
> 
> I think we should try to pressure^H^H^H^H^H^H^H^H kindly convince the
> maintainers/distributers of such programs to offer a sane setup.ini
> for their program.  It would be good not to get these questions,
> except in case of a packaging bug.

Yes.
 
> It means that setup.exe's handling of dependencies is broken and that
> that we're in dire need of versioned pakcage requires: (like Debian
> has) or file dependencies (arguably less user friendly but also works,
> like Red Hat).  To take XEmacs as an example, when libpng got split,
> it's setup.hint (assuming it tries to play nice) should have been
> changed from

Yup. IIRC you where going to put some time into that for setup.exe....
Did you ever get time to do that? We also really need a provides: line
and a versioned conflicts: line.

> That's silly.  If a dependency changes, the package number should be
> increased.  Correctness is more important than bandwidth, if you're
> short on bandwith, just don't run setup.exe too often.

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.
 
> > what is the priority of per-version requirements: and extra
> > patermalistic setup.exe behavior, compared to "setup crashes on XP"?
> 
> Hmm, that's why I have long (pre-setup.exe) wondered why Cygwin would
> not adopt rpm (or dpkg, whichever), and plug in to those development
> resourses.  Yes, I know about the mounting problem that would need to
> be addressed, and setup is a nice gui interface, which seems to be all
> important.  But at times like this, it seems on the one hand such a
> shame that cygwin can only handle the simplest cases of dependencies,
> and on the other hand it would be a shame to invest too much time in a
> problem that has been solved in a number of different ways.

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. Reproducing that isn't
that hard given the current state of setup.exe's codebase. 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.
 
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/