Mail Archives: cygwin/2002/05/31/12:23:18
> -----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/
- Raw text -