This is the mail archive of the
mailing list for the Cygwin project.
RE: Future releases and packages
- To: "'cygwin at sourceware dot cygnus dot com'" <cygwin at sourceware dot cygnus dot com>
- Subject: RE: Future releases and packages
- From: Andrew Dalgleish <andrewd at axonet dot com dot au>
- Date: Thu, 14 Oct 1999 13:20:44 +1000
> -----Original Message-----
> From: Chris Faylor [SMTP:email@example.com]
> Sent: Thursday, October 14, 1999 12:56
> To: Andrew Dalgleish
> Cc: 'firstname.lastname@example.org'
> Subject: Re: Future releases and packages
> On Thu, Oct 14, 1999 at 12:03:29PM +1000, Andrew Dalgleish wrote:
> >[Andrew Dalgleish]
> >Finding volunteers is probably the least of your problems.
> Well, I'm willing to be convinced, but I've mentioned this many times
> and only one person has ever stepped forth.
Count me in.
> >Will the packaging system have to support all possible installation
> Since RPM is ported now, I think it is probably a good alternative.
> I like dpkg, too. That has been ported in the past.
> >It is possible to install cygwin in so (too?) many ways.
> >I use a dedicated drive letter for my root mount and a full FHS-style
> >Other users may want to use a sub-dir for the root, or a simpler
> >directory layout.
> It doesn't really matter. You just specify where the root directory
> be. Then people can either say "c:\" or "i:\my\cygwin\stuff".
Yes, but do we have a full /usr/local/bin, /usr/local/sbin etc, or just
a single /bin?
I try to use FHS where possible, but even something like fileutils
doesn't put everything into the FHS locations.
Even under Linux this can be a problem.
I generally use Debian, but I often get annoyed by packages installed
into a location other than the one envisioned by the original software
If you try to pick up a newer version direct from the author it won't
install into the default Debian location without modifications.
Should we support a sys-v style init?
(I know we don't actually have run-levels, but I like the scripts in one
dir, symlinks in another style approach.)
Some software packages will have support for this already.
> >Then there is the text vs binary issue for scripts, etc in each
> >I'm fairly sure no current Linux package manager has to handle that.
> >(We have to support CR-NL in case the user edits a vital file using
> >but we can't install text files if someone is using binary mounts.)
> There is no issue to worry about when installing a package. Every
> text file has to have \n endings. There is no alternative to this.
If the package contains a list of which files are text, the package
manager can do a post-install conversion.
dpkg can do this, I guess rpm could too.
> After installation, if someone wants to merrily go around setting
> to text or binary mode, then they can do so.
> >Should we say "We support X. If you want Y you are on your own."?
> >There will still be a lot of list traffic for the "Frank Sinatra"
> >"I did everything just like it said in the readme, except different
> That's a good point. However, since the support will primarily be
> via the mailing list, we really don't have to worry about it, IMO.
> If someone uses a wacky installation layout they won't have as much
> of a chance of being answered but eventually Earnie will work up a
> of questions and put it on his web page and then we'll only have to
> "Go to Earnie's web page" repeatedly.
> >Of course none of these are insurmountable problems, but they must be
> >addressed up front.
> The one question that you didn't ask was "GUI or not". I'd like to
> a GUI installer but a lot of people seem to think that's a bad idea.
Personally, I'd opt for text-mode.
(At work, I'm converting our projects from InstallShield 5 to IS6.
They dropped several critical functions from their API.
I definitely recommend *against* using IS.)
Want to unsubscribe from this list?
Send a message to email@example.com