This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: On Cygwin package naming and a setup.exe bug

Christopher Faylor wrote:
>>> Not surprising since this isn't a goal for setup.exe.  It's really only
>>> intended to install cygwin packages.

Okay, but the file I'm talking about *is* a Cygwin package, at least in
the sense in which I was naively using the words.  I was using "Cygwin
package" to mean "package using the Cygwin environment and installable
by Cygwin's setup.exe", i.e., "a file, like grep-2.4.2-1.tar.gz, which is
a [bg]zipped tarball containing executables and such in a /usr/bin, /etc
etc sort of directory hierarchy as described in";

> The PRC-Tools are not distributed from the cygwin web site.  They are
> not an official cygwin package.

Ah, so setup.exe is only intended to install *official* Cygwin packages,
it's not supposed to be a general installation tool.

That's fair enough.  But it seems a shame, because it's so close to
being that general tool.

I'm a vendor with a reasonably non-tiny package who supplies binary
packages for the convenience of the users.  It's a collection of
Unix applications, so of course on Windows we build it as Cygwin

On Linux, building an RPM is easy, and the users have tools to install
such beasts, so it's convenient to build the binary package as an RPM.

On Solaris, building a pkgadd package is not too horrifying, and the
users have tools to install such beasts, so it's convenient to build the
binary package as a pkgadd package.

On Cygwin, building a setup.exe-tarball is easy, and the users have a
tool to install such beasts, so it would be convenient to build the
binary package as a setup.exe-tarball.

In short, I want to think of setup.exe the same way as Bernard Dautrevaux:
as *the* package management tool for Cygwin.  (That's certainly what it
looks like it is when you use it!)

I understand that this was not one of the original design goals.  But it
seems to me that it would not be difficult and would be useful for Cygwin
users (and also for package distributors like me), so I want to open a
discussion on it.

I'm surprised that this seems to be a new thing.  I would have thought
that there would be lots of people wanting to do what I want to do
(distribute a binary package that runs in a Cygwin environment, but which
is not fundamental enough to be worth adding to the list of "official
Cygwin packages" hosted on the Cygwin web site).

People including me have suggested various workarounds that I could use.

Workarounds involving subdirectories and/or symlinks on the server are
in fact irrelevant, so I'm sorry I didn't adequately explain the problem
I'm really trying to address.  I can use symlinks or whatever to set up
whatever complicated stucture I like, but what I'm really trying to do
is avoid confusing the users.

I can use various tricks in my setup.ini file with the existing setup.exe
program to conform to the naming convention and make everything work in
the "Install from Internet" case.  That's fine.  But, in a perfect world,
it would be good if the download-manually-and-"Install from Local
Directory" case worked well too, because I suspect that's what more
knowledgeable users will want to do.

Imagine a perhaps not enormously knowledgeable user who goes to and downloads
a few files, perhaps a source tarball and a binary package, into some
temporary directory.  Regardless of whatever subdirectory or symlink
structure they might have had on the server, on this user's local drive
they are just a bunch of files identified by their names.  Later they come
to look at and/or install these files.  By now, they've forgotten all
about them and the only information they have to go on is the filenames.

If the Cygwin binary package they've downloaded is called
prc-tools-2.1-1.tar.gz, people *will* get confused about the difference
between prc-tools-2.1.tar.gz and prc-tools-2.1-1.tar.gz, and they'll send
me email about it.  I'd like to be able to avoid generating that

I can use various workarounds to do that more or less successfully.
As I suggested, I can call the file prc-tools-2.1-cygwin.tar.gz, with
the side-effect that the version is 2.1-cygwin instead of 2.1.  As Charles
suggested, I can call the file prc-tools-cygwin-2.1.tar.gz, with the
side-effect that the package name will be listed in the UI as
prc-tools-cygwin instead of prc-tools.

This is workable, but not aesthetically satisfying.  I *will* get email
from moronic users asking why "prc-tools 2.1" is listed as "2.1-cygwin"
or "prc-tools-cygwin".  If I provide two source tarballs with different
names -- prc-tools-2.1.tar.gz and prc-tools-2.1-src.tar.gz -- as Charles
suggested, I *will* get email from morons asking what the difference
between them is.

In a perfect world, the Cygwin package naming convention would be
compatible with avoiding all this confusion.

The situation is workable at the moment, and I could just go away and use
one of these workarounds and live in an imperfect world (and just ignore
all the moronic email I'm going to get).  In fact, considering the flame
war that my not especially well explained but well-intentioned posting
seems to have produced, I might do just that. :-)

But this is free software, and I do like to strive for aesthetics and a
perfect world.  It is my opinion that setup.exe can be extended in this
way with very little maintenance burden, so if there's interest in making
life easier for users and developers of non-standard packages like this
running on Cygwin, I do think it's worth discussing and I hope I've
motivated the issue better this time.

I've got another IMHO even better suggestion, which I think poses less risk
to the name parsing, which I'll present if there's interest.  But this
email is already far too long and boring, and I'm out of time right now...

As for the side issue of GPL compliance etc, I don't want to waste your
time by addressing it here.  I thank Christopher for his advisory notes,
but I assure you that I do understand the issues and we do fulfill all our
obligations under the GPL.  Of course, I don't expect anyone to believe
that just because I said so :-), but I do expect to be given the benefit
of the doubt.  If anyone wants to dispute my assurance above, they really
ought to check the facts at first.


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]