public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Re: On Cygwin package naming and a setup.exe bug
@ 2001-08-29  9:20 jmarshall
  2001-08-29 10:10 ` Michael F. March
  0 siblings, 1 reply; 25+ messages in thread
From: jmarshall @ 2001-08-29  9:20 UTC (permalink / raw)
  To: cygwin

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/

^ permalink raw reply	[flat|nested] 25+ messages in thread
* RE: On Cygwin package naming and a setup.exe bug
@ 2001-08-29  6:35 Bernard Dautrevaux
  2001-08-29  7:37 ` Christopher Faylor
  0 siblings, 1 reply; 25+ messages in thread
From: Bernard Dautrevaux @ 2001-08-29  6:35 UTC (permalink / raw)
  To: 'Robert Collins', Bernard Dautrevaux; +Cc: cygwin

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
* RE: On Cygwin package naming and a setup.exe bug
@ 2001-08-29  6:12 Bernard Dautrevaux
  2001-08-29  6:25 ` Robert Collins
  0 siblings, 1 reply; 25+ messages in thread
From: Bernard Dautrevaux @ 2001-08-29  6:12 UTC (permalink / raw)
  To: 'Robert Collins', cygwin

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
* RE: On Cygwin package naming and a setup.exe bug
@ 2001-08-27 13:03 Bernard Dautrevaux
  2001-08-28  7:53 ` Warren Young
  0 siblings, 1 reply; 25+ messages in thread
From: Bernard Dautrevaux @ 2001-08-27 13:03 UTC (permalink / raw)
  To: 'cygwin@cygwin.com'

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
* RE: On Cygwin package naming and a setup.exe bug
@ 2001-08-27 11:16 Bernard Dautrevaux
  2001-08-27 11:42 ` Charles Wilson
  0 siblings, 1 reply; 25+ messages in thread
From: Bernard Dautrevaux @ 2001-08-27 11:16 UTC (permalink / raw)
  To: 'Charles Wilson', cygwin

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
* RE: On Cygwin package naming and a setup.exe bug
@ 2001-08-27 11:03 Bernard Dautrevaux
  2001-08-27 11:37 ` Christopher Faylor
  0 siblings, 1 reply; 25+ messages in thread
From: Bernard Dautrevaux @ 2001-08-27 11:03 UTC (permalink / raw)
  To: 'cygwin@cygwin.com'

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
* On Cygwin package naming and a setup.exe bug
@ 2001-08-26  0:51 John Marshall
  2001-08-26 10:46 ` Christopher Faylor
  0 siblings, 1 reply; 25+ messages in thread
From: John Marshall @ 2001-08-26  0:51 UTC (permalink / raw)
  To: cygwin; +Cc: prc-tools-devel

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/

^ permalink raw reply	[flat|nested] 25+ messages in thread
end of thread, other threads:[~2001-08-29 14:04 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-29  9:20 On Cygwin package naming and a setup.exe bug jmarshall
2001-08-29 10:10 ` Michael F. March
2001-08-29 10:59   ` Alex Malinovich
2001-08-29 11:02   ` Charles S. Wilson
2001-08-29 14:04   ` Michael Schaap
  -- strict thread matches above, loose matches on Subject: below --
2001-08-29  6:35 Bernard Dautrevaux
2001-08-29  7:37 ` Christopher Faylor
2001-08-29  6:12 Bernard Dautrevaux
2001-08-29  6:25 ` Robert Collins
2001-08-29  7:35   ` Christopher Faylor
2001-08-27 13:03 Bernard Dautrevaux
2001-08-28  7:53 ` Warren Young
2001-08-27 11:16 Bernard Dautrevaux
2001-08-27 11:42 ` Charles Wilson
2001-08-27 11:54   ` Christopher Faylor
2001-08-27 11:03 Bernard Dautrevaux
2001-08-27 11:37 ` Christopher Faylor
2001-08-26  0:51 John Marshall
2001-08-26 10:46 ` Christopher Faylor
2001-08-27  3:39   ` Warren Young
2001-08-27 10:39     ` Christopher Faylor
2001-08-27 10:52       ` Charles Wilson
2001-08-28  0:14       ` Robert Collins
2001-08-28  6:00       ` John Marshall
2001-08-29  7:30         ` Christopher Faylor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).