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

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

[jmarshall]

Christopher Faylor wrote:
> 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.

Right.  It's not an official part of the Red Hat distribution.  But it
*is* conveniently installable by the "rpm" tool, or any other tool used
to install Red Hat Package Manager packages.

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

Perhaps you can suggest a succinct name for "tar file containing programs
that use Cygwin and installable by Cygwin's setup.exe".  Clearly the words
I used ("Cygwin package", by comparison with "RPM package") are causing
people who already use those words for something else a lot of confusion.

> [Random packages from Al Buonanno, Joe Blaupunkt, and Irene Trumbauer
> aren't official parts of the Cygwin distribution.]

Okay, I think I get your point.

>> As Charles
>> suggested, I can call the file prc-tools-cygwin-2.1.tar.gz
>
> Actually, I suggested that.  I don't understand why this is horrible.

Both you and Charles suggested this one.  (I'm surprised you don't see
why it is not as nice as it could be.)

    John

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



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

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

[Michael F. March]

Is there a reason why all the packages for Cygwin are not
managed via RPM instead of these compressed tar balls?

----- Original Message ----- 
From: <jmarshall@pop.enterprise.net>
To: <cygwin@cygwin.com>
Sent: Wednesday, August 29, 2001 9:20 AM
Subject: Re: On Cygwin package naming and a setup.exe bug


Christopher Faylor wrote:
> 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.

Right.  It's not an official part of the Red Hat distribution.  But it
*is* conveniently installable by the "rpm" tool, or any other tool used
to install Red Hat Package Manager packages.

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

Perhaps you can suggest a succinct name for "tar file containing programs
that use Cygwin and installable by Cygwin's setup.exe".  Clearly the words
I used ("Cygwin package", by comparison with "RPM package") are causing
people who already use those words for something else a lot of confusion.

> [Random packages from Al Buonanno, Joe Blaupunkt, and Irene Trumbauer
> aren't official parts of the Cygwin distribution.]

Okay, I think I get your point.

>> As Charles
>> suggested, I can call the file prc-tools-cygwin-2.1.tar.gz
>
> Actually, I suggested that.  I don't understand why this is horrible.

Both you and Charles suggested this one.  (I'm surprised you don't see
why it is not as nice as it could be.)

    John

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



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


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

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

[Alex Malinovich]

Last time I checked, the only working version of RPM for Cygwin was 3.
(If memory serves.) And I haven't heard too much discussion from people
who are willing to do modifications to it to make the newer versions
work with cygwin. Though I'd imagine that if a developer writing a
cygwin app wanted to make a v3 RPM and distrubute it that way (with
information on where to get the latest working Cygwin version of RPM) it
would work.

As for the actual OFFICIAL cygwin distribution, I have no idea. I'd
imagine that having setup.exe no one is quite inclined to scrap it in
favor of a completely new setup scheme. That's just pure speculation on
my part however.

-Alex

> -----Original Message-----
> From: cygwin-owner@sources.redhat.com 
> [ mailto:cygwin-owner@sources.redhat.com ] On Behalf Of Michael F. March
> Sent: Wednesday, August 29, 2001 12:08 PM
> To: John Marshall; cygwin@cygwin.com
> Subject: Re: On Cygwin package naming and a setup.exe bug
> 
> 
> Is there a reason why all the packages for Cygwin are not
> managed via RPM instead of these compressed tar balls?
> 
> ----- Original Message ----- 
> From: <jmarshall@pop.enterprise.net>
> To: <cygwin@cygwin.com>
> Sent: Wednesday, August 29, 2001 9:20 AM
> Subject: Re: On Cygwin package naming and a setup.exe bug
> 
> 
> Christopher Faylor wrote:
> > 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.
> 
> Right.  It's not an official part of the Red Hat distribution.  But it
> *is* conveniently installable by the "rpm" tool, or any other 
> tool used
> to install Red Hat Package Manager packages.
> 
> > Hmm.  Now you've got it.  So, why the above confusion?
> 
> Perhaps you can suggest a succinct name for "tar file 
> containing programs
> that use Cygwin and installable by Cygwin's setup.exe".  
> Clearly the words
> I used ("Cygwin package", by comparison with "RPM package") 
> are causing
> people who already use those words for something else a lot 
> of confusion.
> 
> > [Random packages from Al Buonanno, Joe Blaupunkt, and Irene 
> Trumbauer
> > aren't official parts of the Cygwin distribution.]
> 
> Okay, I think I get your point.
> 
> >> As Charles
> >> suggested, I can call the file prc-tools-cygwin-2.1.tar.gz
> >
> > Actually, I suggested that.  I don't understand why this is 
> horrible.
> 
> Both you and Charles suggested this one.  (I'm surprised you don't see
> why it is not as nice as it could be.)
> 
>     John
> 
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
> 
> 
> 
> --
> 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/
> 
> 
> --
> 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/
> 
> 
> 


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

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

[Charles S. Wilson]

Please, not again.  do NOT start this thread AGAIN.  Go back, read the 
archives where this was discussed thoroughly.  Synopsis: not now, 
*maybe* later; many things must happen first.

--Chuck


Michael F. March wrote:

> Is there a reason why all the packages for Cygwin are not
> managed via RPM instead of these compressed tar balls?



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

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

[Michael Schaap]

At 19:08 29-8-2001, Michael F. March wrote:
>Is there a reason why all the packages for Cygwin are not
>managed via RPM instead of these compressed tar balls?

For one, a Cygwin RPM would not be able to install cygwin1.dll.  (That's 
why setup.exe is not a cygwin app.)


>Christopher Faylor wrote:
> > 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.
>
>Right.  It's not an official part of the Red Hat distribution.  But it
>*is* conveniently installable by the "rpm" tool, or any other tool used
>to install Red Hat Package Manager packages.

If I make a tar.gz, it is conveniently installable by the GNU "tar" tool, 
or any other tool used to install tar.gz files.  :-)

-- 
     I always wondered about the meaning of life.   So I looked it
     up in the dictionary under "L" and there it was - the meaning
     of life.  It was not what I expected.                  - Dogbert 


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

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

[Christopher Faylor]

On Wed, Aug 29, 2001 at 03:33:21PM +0200, Bernard Dautrevaux wrote:
>>You might want to subscribe to cygwin-developers to know what is
>>scheduled, or look in the archives.  cygwin@cygwin.com is the general
>>discussion forum, and cygwin-apps is for ported applications.
>>Setup.exe is neither.
>
>I don't subscribe to cygwin-developpers as I'm *not* a developper (I
>regret it but *really* don't have time to), don't want my mailbox to be
>more filled than it already is (not counting the fact that it's not an
>open list IIRC), but setup.exe seems to be discussed so often on the
>general list that...

Hmm, and cygwin1.dll is discussed here, too, so...

And, we discuss releases here quite a lot...

I've seen mount mentioned on a regular basis...

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/

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

[Christopher Faylor]

On Wed, Aug 29, 2001 at 11:25:30PM +1000, Robert Collins wrote:
>You might want to subscribe to cygwin-developers to know what is
>scheduled, or look in the archives. cygwin@cygwin.com is the general
>discussion forum, and cygwin-apps is for ported applications. Setup.exe
>is neither.

Sorry.  cygwin-developers is a closed list.  I have stringent
requirements for subscribing people.  You can peruse it in the web
archives, though, as mentioned.

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/

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

[Christopher Faylor]

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/

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

[Bernard Dautrevaux]

> -----Original Message-----
> From: Robert Collins [ mailto:robert.collins@itdomain.com.au ]
> Sent: Wednesday, August 29, 2001 3:26 PM
> To: Bernard Dautrevaux
> Cc: cygwin@cygwin.com
> Subject: RE: On Cygwin package naming and a setup.exe bug
> 
> 
> On 29 Aug 2001 15:09:46 +0200, Bernard Dautrevaux wrote:
> > 
> > > -----Original Message-----
> > > From: Robert Collins [ mailto:robert.collins@itdomain.com.au ]
> > > Sent: Tuesday, August 28, 2001 9:01 AM
> > > To: cygwin@cygwin.com
> > > Subject: Re: On Cygwin package naming and a setup.exe bug
> > > 
> > > 
> > > Ok... I slept through most of this thread :}. I'm going to 
> > > make a couple
> > > of comments though... to no particular poster/answer.
> 
> (*)
> 
> > > Bernard, I'm not sure how the above underlined comment, 
> when combined
> > > with....
> <snip>
> > It would be if the second statement was due to John... 
> 
> Oops. Well that does make a difference! Remind be not to assume the >
> imply the same author.

That was what I thought :-)

> 
> > In fact I think who's giving John's its paycheck has no 
> importance here;
> > he's producing and using open/free source code, so must 
> obey the rules. 
> 
> I didn't mean to imply paycheck creator, rather
> use-to-which-code-is-put. 

Agreed.

> 
> > The
> > only thing I say is that he must not be suspected of not 
> obeying them, as
> > producing free source should deserve checking before complaining.
> 
> Absolutely agree. Interpretation is all, as usual.
>  
> > Not knowing what is scheduled is obscuring th edebate; 
> knowing for example
> > that there will be a change to the -src special handling 
> (meaning some more
> > general solution will be provided) makes perfect sense at 
> refusing the
> > -cygwin special handling, but was far from evident from the initial
> > discussion.
> 
> You might want to subscribe to cygwin-developers to know what is
> scheduled, or look in the archives. cygwin@cygwin.com is the general
> discussion forum, and cygwin-apps is for ported applications. 
> Setup.exe
> is neither.

I don't subscribe to cygwin-developpers as I'm *not* a developper (I regret
it but *really* don't have time to), don't want my mailbox to be more filled
than it already is (not counting the fact that it's not an open list IIRC),
but setup.exe seems to be discussed so often on the general list that...

> 
> The problem with -src is that it a) precludes having multiple packages
> which are created from the same source (ie libfoo (.dll and 
> binaries) +
> foo-devel (headers and .a files) come from foo-source - the -src
> convention means we need libfoo-src + foo-devel-src which would be the
> same file duplicated :[ and b) is non-inutitive to use in setup.exe -
> how do you as a user install sshd-2.95p4 and download the source to
> sshd-2.95p5 which has a bug you want to fix (which is why you want the
> p4 binary)
> 
> So sources should be explicit metadata, not inferred from the name
> metadata. As to how and when... thats a different story :}.

I fully agree with that.

> 
> > OK, I can understand that, but the problem was not 
> explained, just the fact
> > that the feature was getting in the "mixed feelings" 
> category which need
> > further advice from developers.
> 
> And the developers (all ?5?6? for setup.exe) haven't had time to
> comment. The whole thread occured whilst I was asleep... except maybe
> John's inital request, which I read, and figured as I couldn't provide
> an authoritative answer I'd just wait and see what came up before
> jumping in. 

Yeah; tha'ts the biggest internet problem; one should find a way to get the
clock (and the sun!) indicate the same time all over the world :) :) :)

> 
> > PS: Note that in the above message, only the every first 
> quote was from me,
> > while you seem to say that you were answering to my post...
> 
> Uhmm, late at work again? See (*) above :]

Errr... not really, just get my eye caught by th e"Bernard" on th ebeginning
of the line after ;-( My fault!

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

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

[Robert Collins]

On 29 Aug 2001 15:09:46 +0200, Bernard Dautrevaux wrote:
> 
> > -----Original Message-----
> > From: Robert Collins [ mailto:robert.collins@itdomain.com.au ]
> > Sent: Tuesday, August 28, 2001 9:01 AM
> > To: cygwin@cygwin.com
> > Subject: Re: On Cygwin package naming and a setup.exe bug
> > 
> > 
> > Ok... I slept through most of this thread :}. I'm going to 
> > make a couple
> > of comments though... to no particular poster/answer.

(*)

> > Bernard, I'm not sure how the above underlined comment, when combined
> > with....
<snip>
> It would be if the second statement was due to John... 

Oops. Well that does make a difference! Remind be not to assume the >
imply the same author.

> In fact I think who's giving John's its paycheck has no importance here;
> he's producing and using open/free source code, so must obey the rules. 

I didn't mean to imply paycheck creator, rather
use-to-which-code-is-put. 

> The
> only thing I say is that he must not be suspected of not obeying them, as
> producing free source should deserve checking before complaining.

Absolutely agree. Interpretation is all, as usual.
 
> Not knowing what is scheduled is obscuring th edebate; knowing for example
> that there will be a change to the -src special handling (meaning some more
> general solution will be provided) makes perfect sense at refusing the
> -cygwin special handling, but was far from evident from the initial
> discussion.

You might want to subscribe to cygwin-developers to know what is
scheduled, or look in the archives. cygwin@cygwin.com is the general
discussion forum, and cygwin-apps is for ported applications. Setup.exe
is neither.

The problem with -src is that it a) precludes having multiple packages
which are created from the same source (ie libfoo (.dll and binaries) +
foo-devel (headers and .a files) come from foo-source - the -src
convention means we need libfoo-src + foo-devel-src which would be the
same file duplicated :[ and b) is non-inutitive to use in setup.exe -
how do you as a user install sshd-2.95p4 and download the source to
sshd-2.95p5 which has a bug you want to fix (which is why you want the
p4 binary)

So sources should be explicit metadata, not inferred from the name
metadata. As to how and when... thats a different story :}.

> OK, I can understand that, but the problem was not explained, just the fact
> that the feature was getting in the "mixed feelings" category which need
> further advice from developers.

And the developers (all ?5?6? for setup.exe) haven't had time to
comment. The whole thread occured whilst I was asleep... except maybe
John's inital request, which I read, and figured as I couldn't provide
an authoritative answer I'd just wait and see what came up before
jumping in. 

> PS: Note that in the above message, only the every first quote was from me,
> while you seem to say that you were answering to my post...

Uhmm, late at work again? See (*) above :]

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/

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

[Bernard Dautrevaux]

> -----Original Message-----
> From: Robert Collins [ mailto:robert.collins@itdomain.com.au ]
> Sent: Tuesday, August 28, 2001 9:01 AM
> To: cygwin@cygwin.com
> Subject: Re: On Cygwin package naming and a setup.exe bug
> 
> 
> Ok... I slept through most of this thread :}. I'm going to 
> make a couple
> of comments though... to no particular poster/answer.
> 
> On 27 Aug 2001 13:39:17 -0400, Christopher Faylor wrote:
> > On Mon, Aug 27, 2001 at 04:39:46AM -0600, Warren Young wrote:
> > >Christopher Faylor wrote:
> > >> 
> > >> >On our
> > >> >SourceForge downloads page we distribute a source 
> tarball, a few binary
> > >> >RPMs, and a Cygwin binary package.
>                   ^^^^^^^^^^^^^^^^^^^^^
> Bernard, I'm not sure how the above underlined comment, when combined
> with....
> 
> > >> And a cygwin source package, hopefully, if you want to 
> be in compliance
> > >> with the GPL.  
> > >
> > >Not so.  Section 3c of the GPL exempts noncommercial 
> distributors from
> > >having to carry the source.  They can simply point you to 
> where they
> > >downloaded the code themselves.
>    
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the above underlined paragraph; can be interpreted in any 
> other fashion
> than John is intentionally distributing a cygwin1.dll package, in the
> belief that it is GPL blessed. 

It would be if the second statement was due to John... 

> 
> If John had responded with "But it's *our* software in there in binary
> form, not cygwin1.dll; I meant a binary package of out 
> software compiled
> for use on cygwin" then it would all be different!

I was thinking that the initial post from John should have been read like
this (after all nobody ask if the "rpm" contains the libc.so), but of course
YMMV

> 
> So all comments in the thread that disagree with this should 
> be referred
> to John for clarification. IMO Chris and Chuck are correct.

Let me be clear: I *never* disagree with how Chris and Chuck interpret the
GPL; I was just saying that, as I read it, the original post from John seems
to imply that, most probably, it's "cygwin binary package" was *not*
including cygwin1.dll, so was OK with our *common* interpretation of the GPL
:-)

But of course I would have like (and in fact expected) to have John's
reaction on this.

> 
> OTOH there is a meme floating around somewhere that 3(c) is a
> get-out-of-jail-free card - which it's not. This is a bad meme, that
> should be squashed vigourously.

Oh Yes; I agree with that. I just disagree on the "anybody is playing
incorrectly with the GPL" syndrom one can feel when reading some messages.

> 
> > >You shouldn't give John a hard time; the PRC-Tools project 
> is a free
> > >software project in much the same spirit as Cygwin.  In 
> fact, the two
> > >projects are very similar: a GCC port to a non-Unix 
> platform, for making
> > >binaries native to that platform.
>  
> I don't think Chris gave John a hard time. 'nuff said 
> elsehwere anyway.
>  
> > >Now, if John were still working for Palm and posting from 
> a palm.com
> > >address, you'd be justified in being picky about the GPL.  
> But he's not,
> > >and you shouldn't.
> 
> I'm surprised this one wasn't picked up on!. If Chris doesn't enforce
> the GPL on the open/free source community, how can he expect
> closed-source developers to respect it - especially given it 
> hasn't been
> tested in court.

In fact I think who's giving John's its paycheck has no importance here;
he's producing and using open/free source code, so must obey the rules. The
only thing I say is that he must not be suspected of not obeying them, as
producing free source should deserve checking before complaining.

> 
> > >> I've got mixed feelings about putting concessions for
> > >> other packages in setup.  It isn't really supposed to be 
> a general purpose
> > >> installation tool.
> > >
> > >Keep in mind, this isn't a case of using setup.exe to install a
> > >standalone package.  PRC-Tools on Windows is always used 
> inside a Cygwin
> > >environment.  John is just trying to make it simpler to 
> make a PRC-Tools
> > >distribution tarball that Cygwin's own installation tools 
> will accept
> > >and install.
> 
> It doesn't matter what the "other use of setup is" - setup.exe has
> enough trouble just installing accurately, on the thousands of users
> machines that use it. Adding special case considerations does 
> _not_ make
> sense, and I'd be one of the first folk to provide a patch to  remove
> any such considerations from it. We are already trying to 
> find a way to
> remove the -src special consideration. The proposed patch was a
> significant step backwards. (BTW: I contributed some-large% of the new
> dependency and category handling code - so I suspect I know whereof I
> speak).

OK, no problem; as I already say I just expected discussion on why the
proposed solution was or was not appropriate, but in th initial part of the
thread does not find any clear explanation about why it isn't and what
changes scheduled in setup may render it obsolete.

Not knowing what is scheduled is obscuring th edebate; knowing for example
that there will be a change to the -src special handling (meaning some more
general solution will be provided) makes perfect sense at refusing the
-cygwin special handling, but was far from evident from the initial
discussion.

> 
> > It apparently isn't clear to you that "Cygwin's own 
> installation tools"
> > were meant to install, um, the cygwin packages from the 
> cygwin web site
> > and mirrors.  They don't have accomodations for using other 
> web sites or
> > being bundled as part of a larger package.  That is what I 
> was saying
> > above.
> 
> IMO, adding features that don't carry much maintenance overhead is OK,
> but there certainly won't be any cygwin developer driving 
> such features
> _unless_ they are also going to benefit from them. In this case the
> "feature" was a problem. In others they have been added, with only
> trivial discussion (even when cygwin doesn't really need them).

OK, I can understand that, but the problem was not explained, just the fact
that the feature was getting in the "mixed feelings" category which need
further advice from developers.

	Bernard

PS: Note that in the above message, only the every first quote was from me,
while you seem to say that you were answering to my post...

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

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

[Warren Young]

Bernard Dautrevaux wrote:
> 
> However I must admit that, having read the original posting again, it does
> not positively says what is in the binary PRC-tools cygwin package; we just
> understand the term differently it seems.

I use PRC-Tools regularly, so let me try to add some light to this
heated discussion.  :)

I mainly use the Linux version of PRC-Tools, but the last time I used
the Windows version, it assumed that it was being installed into a
working Cygwin environment.  I'm sure this hasn't changed -- the
PRC-Tools people are only trying to change their installation
mechanism.  Since they assume a working Cygwin environment, setup.exe
should exist on users' systems, so trying to make it flexible enough to
go and fetch PRC-Tools is a reasonable thing to attempt.

The binary tools are built as patched versions of the native ones, and
they do depend on cygwin1.dll, so there is a GPL issue here, but the
PRC-Tools project is not re-distributing anything from Cygwin itself. 
It only uses Cygwin code in the distributed binaries.  

There should be no file conflicts, because the PRC-Tools are built with
entirely different prefixes.  It's a cross-compiler living on the same
system as the native compiler that built it.
-- 
= Warren -- ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

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

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

[John Marshall]

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

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

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

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

    John

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

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

[Robert Collins]

Ok... I slept through most of this thread :}. I'm going to make a couple
of comments though... to no particular poster/answer.

On 27 Aug 2001 13:39:17 -0400, Christopher Faylor wrote:
> On Mon, Aug 27, 2001 at 04:39:46AM -0600, Warren Young wrote:
> >Christopher Faylor wrote:
> >> 
> >> >On our
> >> >SourceForge downloads page we distribute a source tarball, a few binary
> >> >RPMs, and a Cygwin binary package.
                  ^^^^^^^^^^^^^^^^^^^^^
Bernard, I'm not sure how the above underlined comment, when combined
with....

> >> And a cygwin source package, hopefully, if you want to be in compliance
> >> with the GPL.  
> >
> >Not so.  Section 3c of the GPL exempts noncommercial distributors from
> >having to carry the source.  They can simply point you to where they
> >downloaded the code themselves.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the above underlined paragraph; can be interpreted in any other fashion
than John is intentionally distributing a cygwin1.dll package, in the
belief that it is GPL blessed. 

If John had responded with "But it's *our* software in there in binary
form, not cygwin1.dll; I meant a binary package of out software compiled
for use on cygwin" then it would all be different!

So all comments in the thread that disagree with this should be referred
to John for clarification. IMO Chris and Chuck are correct.

OTOH there is a meme floating around somewhere that 3(c) is a
get-out-of-jail-free card - which it's not. This is a bad meme, that
should be squashed vigourously.

> >You shouldn't give John a hard time; the PRC-Tools project is a free
> >software project in much the same spirit as Cygwin.  In fact, the two
> >projects are very similar: a GCC port to a non-Unix platform, for making
> >binaries native to that platform.
 
I don't think Chris gave John a hard time. 'nuff said elsehwere anyway.
 
> >Now, if John were still working for Palm and posting from a palm.com
> >address, you'd be justified in being picky about the GPL.  But he's not,
> >and you shouldn't.

I'm surprised this one wasn't picked up on!. If Chris doesn't enforce
the GPL on the open/free source community, how can he expect
closed-source developers to respect it - especially given it hasn't been
tested in court.

> >> I've got mixed feelings about putting concessions for
> >> other packages in setup.  It isn't really supposed to be a general purpose
> >> installation tool.
> >
> >Keep in mind, this isn't a case of using setup.exe to install a
> >standalone package.  PRC-Tools on Windows is always used inside a Cygwin
> >environment.  John is just trying to make it simpler to make a PRC-Tools
> >distribution tarball that Cygwin's own installation tools will accept
> >and install.

It doesn't matter what the "other use of setup is" - setup.exe has
enough trouble just installing accurately, on the thousands of users
machines that use it. Adding special case considerations does _not_ make
sense, and I'd be one of the first folk to provide a patch to  remove
any such considerations from it. We are already trying to find a way to
remove the -src special consideration. The proposed patch was a
significant step backwards. (BTW: I contributed some-large% of the new
dependency and category handling code - so I suspect I know whereof I
speak).

> It apparently isn't clear to you that "Cygwin's own installation tools"
> were meant to install, um, the cygwin packages from the cygwin web site
> and mirrors.  They don't have accomodations for using other web sites or
> being bundled as part of a larger package.  That is what I was saying
> above.

IMO, adding features that don't carry much maintenance overhead is OK,
but there certainly won't be any cygwin developer driving such features
_unless_ they are also going to benefit from them. In this case the
"feature" was a problem. In others they have been added, with only
trivial discussion (even when cygwin doesn't really need them).

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/

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

[Bernard Dautrevaux]

> -----Original Message-----
> From: Christopher Faylor [ mailto:cgf@redhat.com ]
> Sent: Monday, August 27, 2001 8:37 PM
> To: cygwin@cygwin.com
> Subject: Re: On Cygwin package naming and a setup.exe bug
> 
> 
> On Mon, Aug 27, 2001 at 08:01:59PM +0200, Bernard Dautrevaux wrote:
> >> -----Original Message-----
> >> From: Christopher Faylor [ mailto:cgf@redhat.com ]
> >> Sent: Monday, August 27, 2001 7:39 PM
> >> To: cygwin@cygwin.com
> >> Subject: Re: On Cygwin package naming and a setup.exe bug
> 
> >> Who made the offer to continue to include the sources to 
> whatever is
> >> being distributed?  Not me.  I don't want to have to track the PRC
> >> project and make sure that I don't delete, say, the Cygwin 1.3.2
> >> sources because they are still using them.
> >
> >I think there'(s a bit of misunderstanding here: What john 
> says was that it
> >was distributing:
> >	several binary distributions of PRC-tools (as cygwin tarballs
> >       and RPMs) source distribution of PRC-tools (as a 
> source tarball)
> >
> >He thus complies with the GPL.
> 
> Unless you have downloaded everything and inspected it, you 
> can't make a
> statement like that.

Just a question of terminology: for me a binary distribution *for* Cygwin of
some package expects to be installed on a running Cygwin installation (or do
you expect a binary linux application package to contain a glibc binary
distribution?).

I would have understood your worries about complying with the GPL wrt Cygwin
if it says he were distributing a standalone Windows version of PRC-tools
that use Cygwin. But in this case it would probably have packaged it with
some Windows package manager, not Cygwin's one; at least that the way I
would have worked: if I don't want my user to see cygwin, I don't use the
cygwin installer. If I use it, that's because I expect to find it already on
the system.

However I must admit that, having read the original posting again, it does
not positively says what is in the binary PRC-tools cygwin package; we just
understand the term differently it seems.

> 
> >Note that he explicitely says he was NOT distributing 
> Cygwin, just provide a
> >proper setup.ini so that the setup.exe used to install 
> Cygwin from the
> >official cygwin web site (or any other source AFAAIC). 
> 
> John did not use the word DLL anywhere.  So, I assume that it 
> is possible
> that he is including the DLL.  He mentions a "Cygwin binary 
> package".  I
> don't know what is in this package.  I just offered an advisory note.
> 
> I'm not actively downloading the packages and inspecting them for GPL
> violations so that I can call FSF/Red Hat lawyers.  I'm just offering
> my usual caveat about this because people get it wrong all of 
> the time.
> They make the same assumptions that are being made in this thread and
> get hot and bothered about things that are really cut and dry.
> 
> >I don't see where there would be ANY GPL concern with this 
> (although, as
> >usual, IANAL).
> 
> And as far as I can tell, you don't even have in-depth knowledge about
> what is being offered.

OK, that's sure; I don't scrutinize the PRC-tools binary package (I don't
even know if it's available online fro now). I just try to read and
understand a message but obviously do not understand the same as you. Of
course ANY binary package expected to run under Windows (and especially if
it runs also under Unix) could be the target of a warning about the need to
comply with the GPL if it includes some Cygwin stuff.

However, I think that someone that build open source code could be expected
to know what it does. Note that what you said in your first posting (and
that was the very beginning of your text) was:

* And a cygwin source package, hopefully, if you want to be in compliance
* with the GPL.  If you are providing cygwin1.dll, you must provide sources
* for cygwin1.dll.  If you are providing any other binaries that use
cygwin1.dll
* you most provide sources for them, also.

What I've think a bit rude is jumping immediately to what can be read as a
reprimand: you do not ask if it includes cygwin code, you say first it
should include cygwin sources, then explain it in a way that, by the
negative, explains that it may be OK if it does not provides cygwin1.dll or
any other cygin-using binary.

> 
> >> >You shouldn't give John a hard time; the PRC-Tools 
> project is a free
> >> >software project in much the same spirit as Cygwin.  In 
> fact, the two
> >> >projects are very similar: a GCC port to a non-Unix 
> >> platform, for making
> >> >binaries native to that platform.
> >> 
> >> "Why are you giving me a hard time! I'm a free software 
> >> project!".  Yes,
> >> we hear this from time to time.  The GPL is a legal 
> binding document.
> >> If you want to use it, you should be in compliance with 
> it.  You don't
> >> get to ignore it because you consider yourself "one of the 
> good guys".
> >> It would be nice if life worked that way, but it doesn't.
> >
> >IMHO John is perfectly complying with the GPL. What I would 
> say is, rather
> >than "don't be ruide with me, I'm a free project programmer" 
> would be "Don't
> >start thinking I will not comply with the GPL for your 
> product; I'm already
> >complying for mine, so check before ranting :-)"
> 
> I was not ranting.  I stated a fact.  I did not do it rudely. 

Unfortunately that was not a statement of fact; that was interpretation of
what he says looking at what can be incorrect. I agree there can always be
incorrect uses of GPLed code. The problem is trying to judge how probable is
the violation. Reading his whole message leave me with the impression that
such a probability was quite low, and that's why I reacted after several
message discussing in which way John could be in violation with the GPL.

Note that in fact I completely agree with your position in this part of the
discussion: if there is ANY piece of GPLed code in an on-line binary
distribution, there MUST be an accompanying source code distribution on-line
on the same server; other ways to comply with the GPL are too much arguable
(note the on-line qualifiers above).

>  If you or
> anyone took a statement of fact as rudeness then you have 
> reading skills
> problems.   

That may be the case as it's a bit late to be still at work here :-)

> There may be a mailing list that will deal with this but
> this is not it.
> 
> (In case you are wondering *that* was a rude comment.  You 
> might want to
> compare and contrast to see if you can see the difference)

I think I may deserve it as I may have been a bit rude myself. In fact I was
merely annoyed to see a problem that was interesting masked by YAGPLD (yet
another GPL discussion) and may have react a bit quickly.

> 
> >> >> Not surprising since this isn't a goal for setup.exe.  
> >> It's really only
> >> >> intended to install cygwin packages.
> >> >
> >> >What makes PRC-Tools "not a Cygwin package" and, say, 
> tcltk "a Cygwin
> >> >package"?  Both are programming language systems that 
> live within the
> >> >Cygwin environment.
> >> 
> >> The PRC-Tools are not distributed from the cygwin web 
> site.  They are
> >> not an official cygwin package.  Do I really have to explain this?
> >
> >So, setup.exe is *restricted* to install *official* cygwin 
> packages? a bit
> >too harsh I think.
> 
> Wow.  Density prevails. (more rudeness)
> 
> HANDLING OTHER DISTRIBUTIONS IS NOT A GOAL OF THE CYGWIN 
> SETUP UTILITY.
> 
> Did you happen to read the part where I said "I"d have to get a ruling
> from the other developers..."?
> 
> I also suggested a couple of ways to work around this without 
> modifying
> setup.exe.  I assume that you missed those, too.
> 
> >>It apparently isn't clear to you that "Cygwin's own 
> installation tools"
> >>were meant to install, um, the cygwin packages from the 
> cygwin web site
> >>and mirrors.  They don't have accomodations for using other 
> web sites
> >>or being bundled as part of a larger package.  That is what I was
> >>saying above.
> >
> >Was that a "for now and ever" position, and are then patches to allow
> >to install "unofficial" cygwin packages with setup.exe forcibly
> >refused?
> 
> You've really lost a lot of state from my original message and are
> assigning positions to me that I never took.  I said I had "mixed
> feelings", which is certainly my right.  I said that it would 
> require "a
> ruling" from other developers.  This would indicate that I was willing
> to support other distributions.

What I've understood was that you needed rulings from other developpers to
see if such a patch could break something. Perfectly sensible.

You say then you have mixed feelings about modifying setup.exe to support
installation of other packages or making it a general purpose installation
tool. 

> 
> Any change to setup.exe entails some support overhead.  Adding the
> proposed patch may also not be the right way to handle this.  

Sure; I never said the opposite. What I was angry about is that then nobody
else talk of the proposal.

> The other
> developers may not want to worry about non-core-cygwin releases.  I
> can't believe that I have to keep explaining this.
> 
> >I personally would have think of setup.exe as *the* tool to 
> manage a cygwin
> >installation, like rpm is *the* tool to manage a Red Hat 
> linux install or
> >addpkg is *the* tool to manage a Solaris (or is it an HPux) 
> system. That,
> >for me, has meant that i should try to provide my own 
> packages in a form
> >suitable for installation/uninstallation by setup.exe.
> 
> You can think whatever you want.  Since I was the person who got the
> setup.exe program started and have remained an active 
> contributor to it
> I think I know what was intended.

Yes, but a lot of packages were successfull just because they were usable in
unexpected (and often unintended) ways... I was not arguing about what was
intended, but about how people may usefully use it.

> 
> I am 100% certain that we are not thinking about third-party 
> installation
> problems in any of our discussions about setup.exe.  What 
> that means is
> that it will probably take some discussion before anything like John's
> patch is accepted.

Fine; I was just interested by *this* discussion. In fact if I read the
thread it was due to the subject line and the content of the original
posting (which has nothing to do with the GPL).

> 
> >If I'm wrong, I will then try to use RPM or some other fancy 
> installer and
> >have to tinker it to be able to pick cygwin configuration 
> data so that I
> >install my package in a sensible way, with sensible 
> defaults, in an exsiting
> >cygwin install... Phew, do I really need to do that? ;-(
> 
> This is an open source project.  You can take setup.exe sources and do
> whatever you like with them as long as you adhere to the GPL.
> 
> If you want to start a discussion going on how setup.exe can support
> third-party apps, feel free.  No one is going to stop you.  The flip
> side is that if people are uninterested in this aspect of 
> setup.exe, no
> one is going to help you much either.

What I understood in John's post was just trying to open this discussion.
But then the rest of the thread was discussing whether he was perhaps
violating the GPL...

> 
> Let me just summarize (again can't believe that I have to):
> 
> 1) I'm not mad at John for daring to suggest a change to setup.exe.

I never said that; I said that I would have expected a discussion about the
pros and cons of its proposal, not a "mixed feeling" and "it was not
intended for this use"; these are a bit too vague.

I agree 100% that modifying setup.exe should be done with caution; 4m too
much aware of the complexities of an install manager. But just due to that I
would like to be able to use setup.exe to install "foreign" packages running
under cygwin.

> 
> 2) I don't know if there are GPL issues in the PRC-Tools 
> release.  I was
>    just raising the possibility because people are so often 
> confused about
>    the subject.

I was just willing to argue that, although there may be, it seems to me that
the probability is quite low and deserve probably a more interogative
"statement".

> 
> 3) I accepted the bug fix that John suggested.

Sure; I notice it upfront and never said the opposite. 

> 
> 4) Third-party package setup.exe handling has not been a goal 
> for setup.exe.
>    A patch which adds something for dealing with third-party 
> use does not
>    get blindly accepted.  It gets discussed.

I was only asking for that: discussing it.

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

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

[Christopher Faylor]

On Mon, Aug 27, 2001 at 02:42:27PM -0400, Charles Wilson wrote:
>Well, you have to expect some bitterness.  Count the number of problem 
>reports generated by people who don't even use OUR setup to install 
>cygwin itself.  Geez.

Here is what I said:

*>I'd have to get a ruling from other developers to see if this screws up
*>anything else.  I've got mixed feelings about putting concessions for
*>other packages in setup.  It isn't really supposed to be a general
*>purpose installation tool.

This is the second time in a couple of months that I've gotten a violent
reaction to my suggesting that I'd ask for other people's input.  I
really don't get it.

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/

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

[Charles Wilson]

Bernard Dautrevaux wrote:

> Yeah, I agree, but in all places I know everyone, especially someone without
> a police record, is presumed innocent...


<gratuitous political inflammatory remark>
except here in the USA, w.r.t. the IRS.  Or the drug "war".  Or when 
carrying large sums of cash.  Or when driving-while-black.
</gratuitus political inflammatory remark>
   -- but please don't respond on-list; email me if you want.


> What I've read in the original posting was a discussion of how setup could
> be enhaced to allow installation of unofficial cygwin packages, TOGETHER
> WITH A PATCH and almost a firm commitment to rework it if it proves
> unacceptable.


There were two patches.  One was appropriate and was accepted.  The 
other was held in abeyance pending further discussion.  (Also, given 
that MASSIVE changes have recently happened to setup, yet VERY FEW 
people have tested them, the developers are a bit leary --at this 
point-- to adding yet more stuff, until the current <untested> stuff 
sees wider use.  (New setup should be available RSN))


> I've heard so much answer in the line of "Please provide a patch" for
> proposal of enhancements to setup.exe (and I perfectly understand that) that
> I was a bit bitten by the answer done to a proposal that was carefully
> explained and supplemented by a patch, which was in the line of "We have not
> expected you to use setup.exe for anything else than for what we design it,
> so your proposal was not interesting".


Well, you have to expect some bitterness.  Count the number of problem 
reports generated by people who don't even use OUR setup to install 
cygwin itself.  Geez.

Also, the MAIN motivation for the unaccepted patch was "I don't like the 
  your naming scheme."  (e.g. I want to name my package 
"foo-<ver>-<rev>-cygwin.tar.gz" not "foo-<ver>-<rev>.tar.gz" because the 
latter is too similar to our existing source tarball name 
"foo-<ver>.tar.gz". <umm, how about foo-cygwin-<ver>-<rev>.tar.gz?  No 
setup changes required!>  Also, since our source tarball is named 
foo-<ver>.tar.gz, I don't want to provide a duplicate named 
foo-<ver>-src.tar.gz -- <umm, ever heard of symlinks?>)

Name parsing, as simple as the concept is, is quite difficult to get 
right.  We have a proposal to gratuitously muck with name parsing -- for 
an insufficiently-supported reason, for which there are obvious 
alternatives that don't require mucking with setup.

(Plus, the discussion degenerated into a fight over GPL compliance; very 
little of this thread actually deals directly with the aforementioned patch)


> Please let me be clear: I understand all of you when you answer "requests
> for enhancement" by a "why don't you do it yourself: setup is open source".
> But rebuffing someone that *offers* to do the job, and even propose a first
> possible patch, by just saying "setup was not expected to be used that way"
> is a bit brutal.


Perhaps, but part of "maintaining" is being discriminating about what 
patches are allowed in.  Perhaps "we" can be a bit more politic -- 
"setup is going through changes right now, please ask again after things 
have settled" or "Your case for this proposal is not convincing.  Please 
take this to cygwin-developers and we'll discuss it"

OTOH, it takes a thick skin to work on a public mailing list; if you 
can't take the heat....  Anyway, the cygwin list is remarkably free of 
flames given the disparity in experience levels shown by the 
subscribers.  For some entertainment, read linux-kernel sometime...

--Chuck


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

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

[Christopher Faylor]

On Mon, Aug 27, 2001 at 08:01:59PM +0200, Bernard Dautrevaux wrote:
>> -----Original Message-----
>> From: Christopher Faylor [ mailto:cgf@redhat.com ]
>> Sent: Monday, August 27, 2001 7:39 PM
>> To: cygwin@cygwin.com
>> Subject: Re: On Cygwin package naming and a setup.exe bug

>> Who made the offer to continue to include the sources to whatever is
>> being distributed?  Not me.  I don't want to have to track the PRC
>> project and make sure that I don't delete, say, the Cygwin 1.3.2
>> sources because they are still using them.
>
>I think there'(s a bit of misunderstanding here: What john says was that it
>was distributing:
>	several binary distributions of PRC-tools (as cygwin tarballs
>       and RPMs) source distribution of PRC-tools (as a source tarball)
>
>He thus complies with the GPL.

Unless you have downloaded everything and inspected it, you can't make a
statement like that.

>Note that he explicitely says he was NOT distributing Cygwin, just provide a
>proper setup.ini so that the setup.exe used to install Cygwin from the
>official cygwin web site (or any other source AFAAIC). 

John did not use the word DLL anywhere.  So, I assume that it is possible
that he is including the DLL.  He mentions a "Cygwin binary package".  I
don't know what is in this package.  I just offered an advisory note.

I'm not actively downloading the packages and inspecting them for GPL
violations so that I can call FSF/Red Hat lawyers.  I'm just offering
my usual caveat about this because people get it wrong all of the time.
They make the same assumptions that are being made in this thread and
get hot and bothered about things that are really cut and dry.

>I don't see where there would be ANY GPL concern with this (although, as
>usual, IANAL).

And as far as I can tell, you don't even have in-depth knowledge about
what is being offered.

>> >You shouldn't give John a hard time; the PRC-Tools project is a free
>> >software project in much the same spirit as Cygwin.  In fact, the two
>> >projects are very similar: a GCC port to a non-Unix 
>> platform, for making
>> >binaries native to that platform.
>> 
>> "Why are you giving me a hard time! I'm a free software 
>> project!".  Yes,
>> we hear this from time to time.  The GPL is a legal binding document.
>> If you want to use it, you should be in compliance with it.  You don't
>> get to ignore it because you consider yourself "one of the good guys".
>> It would be nice if life worked that way, but it doesn't.
>
>IMHO John is perfectly complying with the GPL. What I would say is, rather
>than "don't be ruide with me, I'm a free project programmer" would be "Don't
>start thinking I will not comply with the GPL for your product; I'm already
>complying for mine, so check before ranting :-)"

I was not ranting.  I stated a fact.  I did not do it rudely.  If you or
anyone took a statement of fact as rudeness then you have reading skills
problems.   There may be a mailing list that will deal with this but
this is not it.

(In case you are wondering *that* was a rude comment.  You might want to
compare and contrast to see if you can see the difference)

>> >> Not surprising since this isn't a goal for setup.exe.  
>> It's really only
>> >> intended to install cygwin packages.
>> >
>> >What makes PRC-Tools "not a Cygwin package" and, say, tcltk "a Cygwin
>> >package"?  Both are programming language systems that live within the
>> >Cygwin environment.
>> 
>> The PRC-Tools are not distributed from the cygwin web site.  They are
>> not an official cygwin package.  Do I really have to explain this?
>
>So, setup.exe is *restricted* to install *official* cygwin packages? a bit
>too harsh I think.

Wow.  Density prevails. (more rudeness)

HANDLING OTHER DISTRIBUTIONS IS NOT A GOAL OF THE CYGWIN SETUP UTILITY.

Did you happen to read the part where I said "I"d have to get a ruling
from the other developers..."?

I also suggested a couple of ways to work around this without modifying
setup.exe.  I assume that you missed those, too.

>>It apparently isn't clear to you that "Cygwin's own installation tools"
>>were meant to install, um, the cygwin packages from the cygwin web site
>>and mirrors.  They don't have accomodations for using other web sites
>>or being bundled as part of a larger package.  That is what I was
>>saying above.
>
>Was that a "for now and ever" position, and are then patches to allow
>to install "unofficial" cygwin packages with setup.exe forcibly
>refused?

You've really lost a lot of state from my original message and are
assigning positions to me that I never took.  I said I had "mixed
feelings", which is certainly my right.  I said that it would require "a
ruling" from other developers.  This would indicate that I was willing
to support other distributions.

Any change to setup.exe entails some support overhead.  Adding the
proposed patch may also not be the right way to handle this.  The other
developers may not want to worry about non-core-cygwin releases.  I
can't believe that I have to keep explaining this.

>I personally would have think of setup.exe as *the* tool to manage a cygwin
>installation, like rpm is *the* tool to manage a Red Hat linux install or
>addpkg is *the* tool to manage a Solaris (or is it an HPux) system. That,
>for me, has meant that i should try to provide my own packages in a form
>suitable for installation/uninstallation by setup.exe.

You can think whatever you want.  Since I was the person who got the
setup.exe program started and have remained an active contributor to it
I think I know what was intended.

I am 100% certain that we are not thinking about third-party installation
problems in any of our discussions about setup.exe.  What that means is
that it will probably take some discussion before anything like John's
patch is accepted.

>If I'm wrong, I will then try to use RPM or some other fancy installer and
>have to tinker it to be able to pick cygwin configuration data so that I
>install my package in a sensible way, with sensible defaults, in an exsiting
>cygwin install... Phew, do I really need to do that? ;-(

This is an open source project.  You can take setup.exe sources and do
whatever you like with them as long as you adhere to the GPL.

If you want to start a discussion going on how setup.exe can support
third-party apps, feel free.  No one is going to stop you.  The flip
side is that if people are uninterested in this aspect of setup.exe, no
one is going to help you much either.

Let me just summarize (again can't believe that I have to):

1) I'm not mad at John for daring to suggest a change to setup.exe.

2) I don't know if there are GPL issues in the PRC-Tools release.  I was
   just raising the possibility because people are so often confused about
   the subject.

3) I accepted the bug fix that John suggested.

4) Third-party package setup.exe handling has not been a goal for setup.exe.
   A patch which adds something for dealing with third-party use does not
   get blindly accepted.  It gets discussed.

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/

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

[Bernard Dautrevaux]

> -----Original Message-----
> From: Charles Wilson [ mailto:cwilson@ece.gatech.edu ]
> Sent: Monday, August 27, 2001 7:53 PM
> To: cygwin@cygwin.com
> Subject: Re: On Cygwin package naming and a setup.exe bug
> 
> 
> Christopher Faylor wrote:
> 
> > "Why are you giving me a hard time! I'm a free software 
> project!".  Yes,
> > we hear this from time to time.  The GPL is a legal binding 
> document.
> > If you want to use it, you should be in compliance with it. 
>  You don't
> > get to ignore it because you consider yourself "one of the 
> good guys".
> > It would be nice if life worked that way, but it doesn't.
> 
> 
> Yep.  There ain't no sech thing as a "good guys get-out-of-jail-free" 
> clause in the GPL.
> 

Yeah, I agree, but in all places I know everyone, especially someone without
a police record, is presumed innocent...

> 
> > It apparently isn't clear to you that "Cygwin's own 
> installation tools"
> > were meant to install, um, the cygwin packages from the 
> cygwin web site
> > and mirrors.  They don't have accomodations for using other 
> web sites or
> > being bundled as part of a larger package.  That is what I 
> was saying
> > above.
> 
> 
> But remember, setup is open source.  You can grab the sources, modify 
> them to your heart's content, and distribute THAT version of setup to 
> install your cygwin-based add-on packages.  (or just name 
> your package 
> "prc-tools-cygwin-<version>.tar.gz")

What I've read in the original posting was a discussion of how setup could
be enhaced to allow installation of unofficial cygwin packages, TOGETHER
WITH A PATCH and almost a firm commitment to rework it if it proves
unacceptable.

I've heard so much answer in the line of "Please provide a patch" for
proposal of enhancements to setup.exe (and I perfectly understand that) that
I was a bit bitten by the answer done to a proposal that was carefully
explained and supplemented by a patch, which was in the line of "We have not
expected you to use setup.exe for anything else than for what we design it,
so your proposal was not interesting".

> 
> BTW, XEmacs did exactly this:  they're using a *heavily* modified 
> version of cygwin's setup for distributing both the cygwin- 
> and native- 
> versions of XEmacs (they also have other "shrink-wrap" style 
> installers 
> for the native XEmacs).

Yes, but this is a bit different: They use a modified "setup" program to
install XEmacs *everywhere*. The *everywhere* mandates adapting a
cygwin-only installer. But using it to install, on a pre-existing cygwin
installation, a new cygwin package (amthough an unofficial one) seems to be
an use for which setup.exe should be *recommended*, not disdainfully
rejected by saying, "Sorry, I do not think you should do that".

Please let me be clear: I understand all of you when you answer "requests
for enhancement" by a "why don't you do it yourself: setup is open source".
But rebuffing someone that *offers* to do the job, and even propose a first
possible patch, by just saying "setup was not expected to be used that way"
is a bit brutal.

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

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

[Bernard Dautrevaux]

> -----Original Message-----
> From: Christopher Faylor [ mailto:cgf@redhat.com ]
> Sent: Monday, August 27, 2001 7:39 PM
> To: cygwin@cygwin.com
> Subject: Re: On Cygwin package naming and a setup.exe bug
> 
> 
> On Mon, Aug 27, 2001 at 04:39:46AM -0600, Warren Young wrote:
> >Christopher Faylor wrote:
> >> 
> >> >On our
> >> >SourceForge downloads page we distribute a source 
> tarball, a few binary
> >> >RPMs, and a Cygwin binary package.
> >> 
> >> And a cygwin source package, hopefully, if you want to be 
> in compliance
> >> with the GPL.  
> >
> >Not so.  Section 3c of the GPL exempts noncommercial 
> distributors from
> >having to carry the source.  They can simply point you to where they
> >downloaded the code themselves.
> 
> You mean this section:
> 
>     c) Accompany it with the information you received as to the offer
>     to distribute corresponding source code.  (This alternative is
>     allowed only for noncommercial distribution and only if you
>     received the program in object code or executable form with such
>     an offer, in accord with Subsection b above.)
> 
> Who made the offer to continue to include the sources to whatever is
> being distributed?  Not me.  I don't want to have to track the PRC
> project and make sure that I don't delete, say, the Cygwin 1.3.2
> sources because they are still using them.

I think there'(s a bit of misunderstanding here: What john says was that it
was distributing:
	several binary distributions of PRC-tools (as cygwin tarballs and
RPMs)
	one source distribution of PRC-tools (as a source tarball)

He thus complies with the GPL.

Note that he explicitely says he was NOT distributing Cygwin, just provide a
proper setup.ini so that the setup.exe used to install Cygwin from the
official cygwin web site (or any other source AFAAIC). 

I don't see where there would be ANY GPL concern with this (although, as
usual, IANAL).

> 
> >You shouldn't give John a hard time; the PRC-Tools project is a free
> >software project in much the same spirit as Cygwin.  In fact, the two
> >projects are very similar: a GCC port to a non-Unix 
> platform, for making
> >binaries native to that platform.
> 
> "Why are you giving me a hard time! I'm a free software 
> project!".  Yes,
> we hear this from time to time.  The GPL is a legal binding document.
> If you want to use it, you should be in compliance with it.  You don't
> get to ignore it because you consider yourself "one of the good guys".
> It would be nice if life worked that way, but it doesn't.

IMHO John is perfectly complying with the GPL. What I would say is, rather
than "don't be ruide with me, I'm a free project programmer" would be "Don't
start thinking I will not comply with the GPL for your product; I'm already
complying for mine, so check before ranting :-)"
 
> 
> >Now, if John were still working for Palm and posting from a palm.com
> >address, you'd be justified in being picky about the GPL.  
> But he's not,
> >and you shouldn't.

I'm not sure I agree; there is people working for commercial companies
producing GPL code and complying with the GPL; I think you know some :-)

> >
> >> Not surprising since this isn't a goal for setup.exe.  
> It's really only
> >> intended to install cygwin packages.
> >
> >What makes PRC-Tools "not a Cygwin package" and, say, tcltk "a Cygwin
> >package"?  Both are programming language systems that live within the
> >Cygwin environment.
> 
> The PRC-Tools are not distributed from the cygwin web site.  They are
> not an official cygwin package.  Do I really have to explain this?

So, setup.exe is *restricted* to install *official* cygwin packages? a bit
too harsh I think.

> 
> >> I've got mixed feelings about putting concessions for
> >> other packages in setup.  It isn't really supposed to be a 
> general purpose
> >> installation tool.
> >
> >Keep in mind, this isn't a case of using setup.exe to install a
> >standalone package.  PRC-Tools on Windows is always used 
> inside a Cygwin
> >environment.  John is just trying to make it simpler to make 
> a PRC-Tools
> >distribution tarball that Cygwin's own installation tools will accept
> >and install.
> 
> Yes, that was perfectly clear.  Obviously, the whole reason 
> for contacting
> the cygwin mailing list was that PRC tools use Cygwin.  That 
> makes them
> a package that uses cygwin.  It doesn't automatically make 
> them an official
> cygwin package.  Any more than saying that some package that uses RPM
> is an official part of the Red Hat distribution.
> 
> It apparently isn't clear to you that "Cygwin's own 
> installation tools"
> were meant to install, um, the cygwin packages from the 
> cygwin web site
> and mirrors.  They don't have accomodations for using other 
> web sites or
> being bundled as part of a larger package.  That is what I was saying
> above.

Was that a "for now and ever" position, and are then patches to allow to
install "unofficial" cygwin packages with setup.exe forcibly refused? 

I personally would have think of setup.exe as *the* tool to manage a cygwin
installation, like rpm is *the* tool to manage a Red Hat linux install or
addpkg is *the* tool to manage a Solaris (or is it an HPux) system. That,
for me, has meant that i should try to provide my own packages in a form
suitable for installation/uninstallation by setup.exe.

If I'm wrong, I will then try to use RPM or some other fancy installer and
have to tinker it to be able to pick cygwin configuration data so that I
install my package in a sensible way, with sensible defaults, in an exsiting
cygwin install... Phew, do I really need to do that? ;-(

	Regards

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

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

[Charles Wilson]

Christopher Faylor wrote:

> "Why are you giving me a hard time! I'm a free software project!".  Yes,
> we hear this from time to time.  The GPL is a legal binding document.
> If you want to use it, you should be in compliance with it.  You don't
> get to ignore it because you consider yourself "one of the good guys".
> It would be nice if life worked that way, but it doesn't.


Yep.  There ain't no sech thing as a "good guys get-out-of-jail-free" 
clause in the GPL.


> It apparently isn't clear to you that "Cygwin's own installation tools"
> were meant to install, um, the cygwin packages from the cygwin web site
> and mirrors.  They don't have accomodations for using other web sites or
> being bundled as part of a larger package.  That is what I was saying
> above.


But remember, setup is open source.  You can grab the sources, modify 
them to your heart's content, and distribute THAT version of setup to 
install your cygwin-based add-on packages.  (or just name your package 
"prc-tools-cygwin-<version>.tar.gz")

BTW, XEmacs did exactly this:  they're using a *heavily* modified 
version of cygwin's setup for distributing both the cygwin- and native- 
versions of XEmacs (they also have other "shrink-wrap" style installers 
for the native XEmacs).

--Chuck




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

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

[Christopher Faylor]

On Mon, Aug 27, 2001 at 04:39:46AM -0600, Warren Young wrote:
>Christopher Faylor wrote:
>> 
>> >On our
>> >SourceForge downloads page we distribute a source tarball, a few binary
>> >RPMs, and a Cygwin binary package.
>> 
>> And a cygwin source package, hopefully, if you want to be in compliance
>> with the GPL.  
>
>Not so.  Section 3c of the GPL exempts noncommercial distributors from
>having to carry the source.  They can simply point you to where they
>downloaded the code themselves.

You mean this section:

    c) Accompany it with the information you received as to the offer
    to distribute corresponding source code.  (This alternative is
    allowed only for noncommercial distribution and only if you
    received the program in object code or executable form with such
    an offer, in accord with Subsection b above.)

Who made the offer to continue to include the sources to whatever is
being distributed?  Not me.  I don't want to have to track the PRC
project and make sure that I don't delete, say, the Cygwin 1.3.2
sources because they are still using them.

>You shouldn't give John a hard time; the PRC-Tools project is a free
>software project in much the same spirit as Cygwin.  In fact, the two
>projects are very similar: a GCC port to a non-Unix platform, for making
>binaries native to that platform.

"Why are you giving me a hard time! I'm a free software project!".  Yes,
we hear this from time to time.  The GPL is a legal binding document.
If you want to use it, you should be in compliance with it.  You don't
get to ignore it because you consider yourself "one of the good guys".
It would be nice if life worked that way, but it doesn't.

>Now, if John were still working for Palm and posting from a palm.com
>address, you'd be justified in being picky about the GPL.  But he's not,
>and you shouldn't.
>
>> Not surprising since this isn't a goal for setup.exe.  It's really only
>> intended to install cygwin packages.
>
>What makes PRC-Tools "not a Cygwin package" and, say, tcltk "a Cygwin
>package"?  Both are programming language systems that live within the
>Cygwin environment.

The PRC-Tools are not distributed from the cygwin web site.  They are
not an official cygwin package.  Do I really have to explain this?

>> I've got mixed feelings about putting concessions for
>> other packages in setup.  It isn't really supposed to be a general purpose
>> installation tool.
>
>Keep in mind, this isn't a case of using setup.exe to install a
>standalone package.  PRC-Tools on Windows is always used inside a Cygwin
>environment.  John is just trying to make it simpler to make a PRC-Tools
>distribution tarball that Cygwin's own installation tools will accept
>and install.

Yes, that was perfectly clear.  Obviously, the whole reason for contacting
the cygwin mailing list was that PRC tools use Cygwin.  That makes them
a package that uses cygwin.  It doesn't automatically make them an official
cygwin package.  Any more than saying that some package that uses RPM
is an official part of the Red Hat distribution.

It apparently isn't clear to you that "Cygwin's own installation tools"
were meant to install, um, the cygwin packages from the cygwin web site
and mirrors.  They don't have accomodations for using other web sites or
being bundled as part of a larger package.  That is what I was saying
above.

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/

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

[Warren Young]

Christopher Faylor wrote:
> 
> >On our
> >SourceForge downloads page we distribute a source tarball, a few binary
> >RPMs, and a Cygwin binary package.
> 
> And a cygwin source package, hopefully, if you want to be in compliance
> with the GPL.  

Not so.  Section 3c of the GPL exempts noncommercial distributors from
having to carry the source.  They can simply point you to where they
downloaded the code themselves.

You shouldn't give John a hard time; the PRC-Tools project is a free
software project in much the same spirit as Cygwin.  In fact, the two
projects are very similar: a GCC port to a non-Unix platform, for making
binaries native to that platform.

Now, if John were still working for Palm and posting from a palm.com
address, you'd be justified in being picky about the GPL.  But he's not,
and you shouldn't.

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

What makes PRC-Tools "not a Cygwin package" and, say, tcltk "a Cygwin
package"?  Both are programming language systems that live within the
Cygwin environment.

> I've got mixed feelings about putting concessions for
> other packages in setup.  It isn't really supposed to be a general purpose
> installation tool.

Keep in mind, this isn't a case of using setup.exe to install a
standalone package.  PRC-Tools on Windows is always used inside a Cygwin
environment.  John is just trying to make it simpler to make a PRC-Tools
distribution tarball that Cygwin's own installation tools will accept
and install.
-- 
= Warren Young, maintainer of the Palm OS Programmer's FAQ at:
=     http://www.cyberport.com/~tangent/palm/faq/
= 
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

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

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

[Christopher Faylor]

On Sun, Aug 26, 2001 at 08:50:19AM +0100, John Marshall wrote:
> http://sources.redhat.com/cygwin/setup.html says
>
>   Recommended package versioning scheme: use the vendor's version plus a
>   suffix  for ports of existing packages (i.e. bash 2.04 becomes 2.04-1,
>   2.04-2,  etc,  until bash 2.05 is ported, which would be 2.05-1, etc).
>   For  experimental  builds,  use  a  YYYYMMDD  datestamp  version (like
>   bash-20000901.tar.gz).  Binary  tarballs  are "package-version.tar.gz"
>   while source tarballs are "package-version-src.tar.gz".
>
>Hi, I'm a vendor. :-)
>
>I'm the maintainer of prc-tools, which is a big nasty package
>encapsulating GCC and a few other tools targetting Palm OS.  On our
>SourceForge downloads page we distribute a source tarball, a few binary
>RPMs, and a Cygwin binary package.

And a cygwin source package, hopefully, if you want to be in compliance
with the GPL.  If you are providing cygwin1.dll, you must provide sources
for cygwin1.dll.  If you are providing any other binaries that use cygwin1.dll
you most provide sources for them, also.

>However, setup.exe's package naming convention doesn't work especially
>well when an original vendor like me is producing a Cygwin package.

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

>For example, for version 2.1, we (will) have
>
>	source tarball		prc-tools-2.1.tar.gz
>	Linux x86 RPM		prc-tools-2.1-1.i386.rpm
>	Cygwin package		um...  that's why I'm writing...
>
>The problem is that the Cygwin package filename doesn't say "cygwin"
>anywhere.  I don't much want to call it "prc-tools-2.1-1.tar.gz" because
>that's too similar to the source tarball's name and will cause confusion.
>It would be nice if the convention allowed a filename that was a bit more
>self-identifying.  And because we're the vendor, we don't much want to
>have a separate "prc-tools-2.1-1-src.tar.gz" because it'll be exactly the
>same as the main source tarball.

Sounds like a separate subdirectory would solve the problem.

>So far, I've been calling the binary tarball "prc-tools-2.1-cygwin.tar.gz",
>and listing the two in our setup.ini as:
>
>	@ prc-tools
>	version: 2.1
>	install: contrib/prc-tools/prc-tools-2.1-cygwin.tar.gz 3988138
>	source: contrib/prc-tools/prc-tools-2.1.tar.gz 284098
>
>This works well in the "Install from Internet" case.  However, in the
>"Install from Local Directory" case (with or without a setup.ini file)
>do_choose() does a directory scan and finds something whose version it
>thinks is "2.1-cygwin" and things get confusing (I can go into details
>if you want -- and in the case of the source package things get very
>confused indeed).  You get the funky version number when you rerun
>setup.exe, perhaps to uninstall prc-tools, too.

I.e., the version mechanism is doing what it was designed to do.  If you
are going to put a cygwin after the numeric version, it will interpret
the cygwin as part of the version.

>Or I could change the version line to "version: 2.1-cygwin" and train
>the users to believe that when setup.exe says "2.1-cygwin" it really is
>the same as version "2.1".  But that's a bit ugly.

Why not just put the cygwin- first rather than last?  Or use a subdirectory?

>For my purposes, it would be nice if parse_filename() treated "-cygwin"
>as not part of the version, similarly to "-src" and "-patch".  I've been
>playing with this patch:
>
>--- choose.cc.orig	Fri Aug 17 14:01:22 2001
>+++ choose.cc	Fri Aug 24 14:40:47 2001
>@@ -1280,6 +1280,10 @@ parse_filename (const char *in_fn, filep
> 	  p = f.pkgtar + (p - fn) + 6;
> 	  memcpy (p - 6, p, strlen (p));
> 	}
>+      else if ((p -= 1) >= ver && strcasecmp (p, "-cygwin") == 0)
>+	{
>+	  *p = '\0';
>+	}
>     }
> 
>   strcpy (f.ver, *ver ? ver : "0.0");
>
>which makes it treat "package-version-cygwin.tar.gz" just the same as
>"package-version.tar.gz".  This works very nicely, presenting the
>unadorned "2.1" version number even in the "download just the one file
>and point setup at it" case.
>
>So now I'm wondering whether you folks might think something like that
>would be an acceptable idea...

I'd have to get a ruling from other developers to see if this screws
up anything else.  I've got mixed feelings about putting concessions for
other packages in setup.  It isn't really supposed to be a general purpose
installation tool.

>Using "Install from Local Directory" on a directory containing a single
>file named prc-tools-2.1-cygwin.tar.gz worked in setup 2.57.  But in the
>current 2.78.2.3 you get "Nothing to Install/Update" because fromcwd.cc
>has a bug where it creates a Package record for each file it sees, but
>with a random package name.  Later scan2() looks for a record with the
>right name, doesn't find one, and so doesn't set any existence flags.
>Then the randomly named package winds up being excluded by
>set_existence(), and there's nothing left :-(.
>
>It's easily fixed:
>
>--- fromcwd.cc.orig	Sun May 27 08:05:09 2001
>+++ fromcwd.cc	Fri Aug 24 14:42:31 2001
>@@ -87,7 +87,6 @@ static void
> found_file (char *path, unsigned int fsize)
> {
>   fileparse f;
>-  char base[_MAX_PATH];
> 
>   if (!parse_filename (path, f))
>     return;
>@@ -104,7 +103,7 @@ found_file (char *path, unsigned int fsi
>       }
> 
>   if (p == NULL)
>-      p = new_package (strdup (base));
>+      p = new_package (f.pkg);
> 
>   int trust = is_test_version (f.ver) ? TRUST_TEST : TRUST_CURR;
> 
>
>(This is against the current CVS HEAD, in which new_package() strdups its
>name parameter itself.)

Thanks for the patch.  I've applied it to CVS.

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/

On Cygwin package naming and a setup.exe bug

[John Marshall]

http://sources.redhat.com/cygwin/setup.html says

   Recommended package versioning scheme: use the vendor's version plus a
   suffix  for ports of existing packages (i.e. bash 2.04 becomes 2.04-1,
   2.04-2,  etc,  until bash 2.05 is ported, which would be 2.05-1, etc).
   For  experimental  builds,  use  a  YYYYMMDD  datestamp  version (like
   bash-20000901.tar.gz).  Binary  tarballs  are "package-version.tar.gz"
   while source tarballs are "package-version-src.tar.gz".

Hi, I'm a vendor. :-)

I'm the maintainer of prc-tools, which is a big nasty package
encapsulating GCC and a few other tools targetting Palm OS.  On our
SourceForge downloads page we distribute a source tarball, a few binary
RPMs, and a Cygwin binary package.

Way back when, producing something our users could install with Cygwin
B20.1 was a nightmare involving InstallShield.  But I'm very happy these
days that I just have to make tarballs that are usable with Cygwin's
shiny new setup.exe utility.  I've been telling people to download the
package from SourceForge into an empty directory (i.e., without any
setup.ini lying around) and then use setup.exe's "Install from Local
Directory" (which doesn't work anymore: see below), and lately I've been
playing with having our own setup.ini file that lists just our package,
and telling the users to use our website as a setup.exe "Other URL"
mirror, which is even easier for them.

However, setup.exe's package naming convention doesn't work especially
well when an original vendor like me is producing a Cygwin package.

For example, for version 2.1, we (will) have

	source tarball		prc-tools-2.1.tar.gz
	Linux x86 RPM		prc-tools-2.1-1.i386.rpm
	Cygwin package		um...  that's why I'm writing...

The problem is that the Cygwin package filename doesn't say "cygwin"
anywhere.  I don't much want to call it "prc-tools-2.1-1.tar.gz" because
that's too similar to the source tarball's name and will cause confusion.
It would be nice if the convention allowed a filename that was a bit more
self-identifying.  And because we're the vendor, we don't much want to
have a separate "prc-tools-2.1-1-src.tar.gz" because it'll be exactly the
same as the main source tarball.

So far, I've been calling the binary tarball "prc-tools-2.1-cygwin.tar.gz",
and listing the two in our setup.ini as:

	@ prc-tools
	version: 2.1
	install: contrib/prc-tools/prc-tools-2.1-cygwin.tar.gz 3988138
	source: contrib/prc-tools/prc-tools-2.1.tar.gz 284098

This works well in the "Install from Internet" case.  However, in the
"Install from Local Directory" case (with or without a setup.ini file)
do_choose() does a directory scan and finds something whose version it
thinks is "2.1-cygwin" and things get confusing (I can go into details
if you want -- and in the case of the source package things get very
confused indeed).  You get the funky version number when you rerun
setup.exe, perhaps to uninstall prc-tools, too.

Or I could change the version line to "version: 2.1-cygwin" and train
the users to believe that when setup.exe says "2.1-cygwin" it really is
the same as version "2.1".  But that's a bit ugly.

For my purposes, it would be nice if parse_filename() treated "-cygwin"
as not part of the version, similarly to "-src" and "-patch".  I've been
playing with this patch:

--- choose.cc.orig	Fri Aug 17 14:01:22 2001
+++ choose.cc	Fri Aug 24 14:40:47 2001
@@ -1280,6 +1280,10 @@ parse_filename (const char *in_fn, filep
 	  p = f.pkgtar + (p - fn) + 6;
 	  memcpy (p - 6, p, strlen (p));
 	}
+      else if ((p -= 1) >= ver && strcasecmp (p, "-cygwin") == 0)
+	{
+	  *p = '\0';
+	}
     }
 
   strcpy (f.ver, *ver ? ver : "0.0");

which makes it treat "package-version-cygwin.tar.gz" just the same as
"package-version.tar.gz".  This works very nicely, presenting the
unadorned "2.1" version number even in the "download just the one file
and point setup at it" case.

So now I'm wondering whether you folks might think something like that
would be an acceptable idea...

The source tarball is harder to solve.  But I'm not too worried about
that:  I think the best thing to do will probably be just to not list a
source tarball in our setup.ini file, and get the little N/A box instead
of a Source? checkbox.  Cygwin people who want the source code can just
download the source tarball from the downloads web page just like
anybody else.  So we don't need to do anything special.


Using "Install from Local Directory" on a directory containing a single
file named prc-tools-2.1-cygwin.tar.gz worked in setup 2.57.  But in the
current 2.78.2.3 you get "Nothing to Install/Update" because fromcwd.cc
has a bug where it creates a Package record for each file it sees, but
with a random package name.  Later scan2() looks for a record with the
right name, doesn't find one, and so doesn't set any existence flags.
Then the randomly named package winds up being excluded by
set_existence(), and there's nothing left :-(.

It's easily fixed:

--- fromcwd.cc.orig	Sun May 27 08:05:09 2001
+++ fromcwd.cc	Fri Aug 24 14:42:31 2001
@@ -87,7 +87,6 @@ static void
 found_file (char *path, unsigned int fsize)
 {
   fileparse f;
-  char base[_MAX_PATH];
 
   if (!parse_filename (path, f))
     return;
@@ -104,7 +103,7 @@ found_file (char *path, unsigned int fsi
       }
 
   if (p == NULL)
-      p = new_package (strdup (base));
+      p = new_package (f.pkg);
 
   int trust = is_test_version (f.ver) ? TRUST_TEST : TRUST_CURR;
 

(This is against the current CVS HEAD, in which new_package() strdups its
name parameter itself.)

    John

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