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

[Christopher Faylor <cgf at redhat dot com>]

On Tue, Aug 28, 2001 at 02:00:25PM +0100, John Marshall wrote:
>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
>http://cygwin.com/ml/cygwin-apps/2000-11/msg00055.html.";

Wow.  How many times do I have to explain this distinction?

If I make an RPM, that does not mean that said RPM is now an official
part of the Red Hat distribution.  It means that it is a Red Hat Package
Manager file.

If I make a tar file containing programs that use cygwin, that does not
mean that it is part of the official cygwin distribution.  It means
that it is a tar file containing files that use cygwin.

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

Hmm.  Now you've got it.  So, why the above confusion?

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

Sure.  As has been pointed out elsewhere, sometimes tools can be used
in a more general way than what they were designed for.

>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 don't think that anyone fails to grasp the idea that you and Bernard
want to use setup.exe for other things.  Since the tool, in its default
state, automatically downloads cygwin from the web, it obviously is
intended as the cygwin distribution installation utility.

If you set things up correctly, setup.exe will install "other" tar files
that it finds in the download directory.  Does that mean that it is a
bug that you can't use setup.exe to download anything but the cygwin
distribution?  I suppose a leap of imagination might lead you to
conclude that the installer was somehow half finished since it only
seems to be good at installing non-distribution packages that you
download by hand.

Also, you can, of course, make a case for why you think that setup.exe
should be a word processor.  That doesn't mean that anyone is interested
in making setup.exe into a word processor.  That's the real problem here.
This seems to be the standard free software scenario of people wanting
stuff really bad and getting bothered when the developers don't seem to
be inclined to move in that direction.

(This is not directed at John who is actually obviously thinking about the
issues and supplying honest-to-gosh patches.)

Btw, by cygwin distribution, I don't mean some package of shell scripts
distributed by Al Buonanno which use cygwin and ash to send random
bird calls to the sound port as alarms.  I'm talking about the cygwin
distribution as distributed from sources.redhat.com.

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

I'm surprised that you are surprised, since you seem to have looked at
the source code.

Haven't you noticed that setup.exe goes straight to sources.redhat.com
to retrieve its list of *cygwin* mirrors so that it can download the
*cygwin* setup.ini file?

And, by *cygwin*, I don't mean something like Joe Blaupunkt's
cygwin-using package to keep track of baseball cards.  I mean the
*official* *cygwin* *distribution*.

Since setup.exe is specifically grabbing the cygwin distribution, it
obviously is not a general-purpose install tool.  Sure, you can use it
that way but it has a long ways to go before it is acceptable for this
purpose.

So, unless you are modifying setup.exe for your own uses, I can easily
imagine the plaintive mailing lists cries "I tried to setup.exe the
PRC-tools but they don't show up! I've uninstalled and reinstalled
cygwin 27 times but they still are not there!"

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

I suspect that most users would expect that setup.exe would be able to
download a package using the same mechanism as they used to download
the official cygwin distribution and would be potentially confused
by the fact that installing add-ons required other manual steps.

By the way, when I say "official cygwin distribution" I don't mean
something like a random cygwin package distributed by Irene Trumbauer to
keep track of rare Harley-Davidson motorcycle parts.  I'm referring to
the cygwin distribution as hosted at sources.redhat.com.

>Imagine a perhaps not enormously knowledgeable user who goes to
>http://sourceforge.net/project/showfiles.php?group_id=4429 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
>confusion.

So, name the cygwin tools: prc-tools-cygwin-2.1-1.tar.gz.

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

Actually, I suggested that.  I don't understand why this is horrible.

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

And *we* will get mail asking why setup.exe isn't installing PRC-tools
like it should.

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

I guess I have a hard time believing that someone would contact you if
they saw a -cygwin attached to anything.  I'm about as pessimistic about
moronic email as is possible to get but I really don't see getting a lot
of email about this.  YMMV, I guess.

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

The bottom line is that, when we fix something in setup.exe, we don't like
to do half measures if we can avoid it.  I don't see adding -cygwin as
anything besides a half-measure.

If we are going to add third-party installation support then it needs to
be discussed and designed.  For discussion to take place we'd need to
actually get people interested.  I don't know if that is possible.

I've asked for feedback on this issue in the mailing list devoted to
developing setup.exe and so far the only responses have been "Lets just
get it working right for the cygwin distribution installation".  That
probably means that no one is interested in taking on this support
burden.

If you want to sign on as the person who champions third-party
installation via setup.exe and you would be willing to address all
concerns, that would be great.  Otherwise, we seem to already have our
hands full with a limited number of developers with a limited amount of
time.

And by "cygwin distribution installation", I am quite sure that the
other developers are not referring to some collection of programs built
in the cygwin environment and packaged by Frank Lambros to manage his
Alf pog collection.  I'm referring to the cygwin distribution from
cygwin.com (aka sources.redhat.com).

>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
>http://prc-tools.sourceforge.net/ first.

That is exactly the assurance that I was looking for.  I do believe you
just because you said so.

I've had a number of encounters with people who distribute cygwin
compiled binaries who are confused by the GPL.  Often these are the
people who are confused by the GPL and don't really want to understand
what they need to do to comply.  Sometimes they are quite hostile and
think that I'm badgering them.  Usually they are reasonable and
interested in finding out what exactly they need to do.

So, mentioning it is now a reflexive behavior.  I wasn't even looking
for reassurance.  I was just performing due diligence.

I do appreciate all of your feedback.

I hope that what I mean by "the cygwin distribution" and "cygwin
packages" is now clear, at least, even if nothing else is.

cgf

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