Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
=== - Original Message - From: "Corinna Vinschen" <[EMAIL PROTECTED]> > Oh, DoD? Dinner on Desktop? Close, DBK Dinner Beside Keyboard :} Rob
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
On Mon, Jan 14, 2002 at 09:34:21PM +1100, Robert Collins wrote: > > === > - Original Message - > From: "Corinna Vinschen" <[EMAIL PROTECTED]> > > > > otflwmmf. > > > > wslpfrmpft? > > I missed the R. > > Rolling On The Floor Laughing With My Mouth Full. It was dinner time :}. Oh, DoD? Dinner on Desktop? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
=== - Original Message - From: "Corinna Vinschen" <[EMAIL PROTECTED]> > > otflwmmf. > > wslpfrmpft? I missed the R. Rolling On The Floor Laughing With My Mouth Full. It was dinner time :}. Rob
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
On Mon, Jan 14, 2002 at 09:23:46PM +1100, Robert Collins wrote: > > === > - Original Message - > From: "Charles Wilson" <[EMAIL PROTECTED]> > > > Hmmm...I must spend too much time with computers. My human brain > parsed > > tetex-beta-20001218-2 as "tetex-beta" "20001218" "2". > > > > You have been using tetex as an example of how setup/upset *misparses* > a > > string, while I thought it was a perfect example of good parsing. :-) > > otflwmmf. wslpfrmpft? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
WARNING: Rathole time. - Original Message - From: "Christopher Faylor" <[EMAIL PROTECTED]> > I shudder at the thought of trying > to sort versions if beta is part of the version number. Why? We're doing alpha sorting now. Rob
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
=== - Original Message - From: "Charles Wilson" <[EMAIL PROTECTED]> > Hmmm...I must spend too much time with computers. My human brain parsed > tetex-beta-20001218-2 as "tetex-beta" "20001218" "2". > > You have been using tetex as an example of how setup/upset *misparses* a > string, while I thought it was a perfect example of good parsing. :-) otflwmmf. Rob
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
On Sun, Jan 13, 2002 at 04:15:46PM -0500, Charles Wilson wrote: >Robert Collins wrote: >>AH yes - thus showcasing the point at hand: >>"tetex" - "beta-20001218" - "cygver" is parsed as >>"tetex-beta" - "20001218" - "cygver"! > > >Hmmm...I must spend too much time with computers. My human brain parsed >tetex-beta-20001218-2 as "tetex-beta" "20001218" "2". > >You have been using tetex as an example of how setup/upset *misparses* a >string, while I thought it was a perfect example of good parsing. :-) Me too. It's the "tetex-beta" package. I shudder at the thought of trying to sort versions if beta is part of the version number. cgf
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
Robert Collins wrote: > > AH yes - thus showcasing the point at hand: > "tetex" - "beta-20001218" - "cygver" is parsed as > "tetex-beta" - "20001218" - "cygver"! Hmmm...I must spend too much time with computers. My human brain parsed tetex-beta-20001218-2 as "tetex-beta" "20001218" "2". You have been using tetex as an example of how setup/upset *misparses* a string, while I thought it was a perfect example of good parsing. :-) --Chuck
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
- Original Message - From: "Charles Wilson" <[EMAIL PROTECTED]> > >>Correct -- it does work from R to L. If we cannot depend on this > >>behavior, then we must rename the following packages: > >> > > > > Which is one of the implications of the thread where you said > > http://cygwin.com/ml/cygwin-apps/2002-01/msg00208.html. > > > Well, consider it a thinko on my part. I was considering > "foo-alphabetic-version-release" different from > "foo-numeric-version-release" -- but of course, version can have > alphabetic characters in it, and my bzip example had numerals in the > "extra" field. > > So both cases really just boil down to: there are four pegs and only > three slots. > I think this is a social problem, not a software engineering problem. > Either way you are imposing a requirement on packagers: Uh-huh :}. > I think we are already doing (a) -- so why not just make that policy, > and go with it...and force upset/setup to obey. The difference between a and b being that a allows package-long-description-ver-rel.tar.gz whereas b requires package-ver-rel.tar.gz ? Frankly I'd prefer b (scales better), and I thought we'd made that policy already (but http://www.cygwin.com/setup.html#naming doesn't cover this). Interesting to note that the next section specifies that the version _must_ start with a digit, which leads to the tetex mis-parsing you highlit below. > > The other question, is - should '-' or '_' go between name, version and > > cygwin-version? > > > '-' definitely. . > I don't really see a difference between tetex-beta and tetex_beta. > Either is fine with me (actually, I believe it should be just 'tetex'. > Doesn't the fact that it has a version number of 20001218 indicate that > the source was taken from CVS and is therefore, by definition, "beta"?) AH yes - thus showcasing the point at hand: "tetex" - "beta-20001218" - "cygver" is parsed as "tetex-beta" - "20001218" - "cygver"! However my point about -/_ was on readability, not just tetex! Rob
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
On Sun, Jan 13, 2002 at 01:31:02PM -0500, Charles Wilson wrote: >Christopher Faylor wrote: >>I don't see any reason to rename libtool-devel to libtool_devel, though. >>It is only a problem when there is a number involved after the dash. >>There are other packages which use dashes in their names. > > >right -- and robert is (tentatively?) advocating a CHANGE in that -- >disallowing '-' within the pkgname field. It looks like you, me, and >Corinna all prefer the status quo: dashes okay, and require parsing from >R to L, so that the final two '-' delimited fields (of N >= 3) are VER >and REL. Ah. I missed that. Sorry. I tend to phase out when we start long threads arguing about minutia. My bad. I thought we were just saying that underscore and dash shouldn't default to the same thing. I've just gone back and reread the thread again and see where Robert suggested that possibly we should always use underscore in package names. I, as always, come down on the side of the computer. If the computer has been able to parse the current tar files and has basically been doing so for almost two years, I don't see any reason to mistrust its ability to continue to do so. It makes parsing easier, for sure, but we've already crossed that Rubicon so I don't see any reason to be more restrictive -- especially since we can't always control package naming. Every bit of wiggle room that we provide means that we don't have to be involved in a debate when people want to provide a new package like, say, an "ace-of-penguins" package. This is DJ's program and it is available via Debian. The only reason I see to use an underscore is when there is a number involved. cgf
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
Christopher Faylor wrote: > On Sun, Jan 13, 2002 at 12:14:24PM -0500, Charles Wilson wrote: > >>Christopher Faylor wrote: >> >>>Didn't I already vote on this? I can't remember. >>> >>>I say "just do it", too. >>> >>I'm waiting for resolution/consensus on the '-' vs. '_' issue...if we >>*are* going to rename auto*-[stable|devel] to auto*_[stable|devel], I >>don't want to have to rename the libtool packages too. I want them >>named "correctly" from the beginning. >> > > I thought that the consensus (i.e., Robert and me) was that '_' shouldn't > be special. Correct, but I'm referring to a different '-' vs. '_' issue -- the one you outline below: > > I don't see any reason to rename libtool-devel to libtool_devel, though. > It is only a problem when there is a number involved after the dash. > There are other packages which use dashes in their names. right -- and robert is (tentatively?) advocating a CHANGE in that -- disallowing '-' within the pkgname field. It looks like you, me, and Corinna all prefer the status quo: dashes okay, and require parsing from R to L, so that the final two '-' delimited fields (of N >= 3) are VER and REL. So, xxx-yyy-zzz-VER-REL has five "fields" (even though we presume that xxx-yyy-zzz is the actual pkgname, '-' characters and all). When parsed R to L, you end up with field #5 =REL, field #4 =VER, and "the rest" = name. Robert is worried about the fragility of that scheme, and (may) be advocating a requirement so that: xxx_yyy_zzz-VER-REL has specifically 3 '-' delimited fields. No confusion. Field #1 =name. Field #2=VER. Field #3=REL. This requires renaming five existing packages, and impacts the naming of my proposed libtool packages. --Chuck
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
On Sun, Jan 13, 2002 at 12:14:24PM -0500, Charles Wilson wrote: >Christopher Faylor wrote: >>Didn't I already vote on this? I can't remember. >> >>I say "just do it", too. > >I'm waiting for resolution/consensus on the '-' vs. '_' issue...if we >*are* going to rename auto*-[stable|devel] to auto*_[stable|devel], I >don't want to have to rename the libtool packages too. I want them >named "correctly" from the beginning. I thought that the consensus (i.e., Robert and me) was that '_' shouldn't be special. I don't see any reason to rename libtool-devel to libtool_devel, though. It is only a problem when there is a number involved after the dash. There are other packages which use dashes in their names. cgf
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
Christopher Faylor wrote: > Didn't I already vote on this? I can't remember. > > I say "just do it", too. I'm waiting for resolution/consensus on the '-' vs. '_' issue...if we *are* going to rename auto*-[stable|devel] to auto*_[stable|devel], I don't want to have to rename the libtool packages too. I want them named "correctly" from the beginning. --Chuck
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
On Sun, Jan 13, 2002 at 06:46:25PM +1100, Robert Collins wrote: > >=== >- Original Message - >From: "Charles Wilson" <[EMAIL PROTECTED]> > >Oh, and on voting for this package: IMO just upload it. > >It's a very core package, required for many apps, and the patches are >going into libtool-HEAD. > >Chris has a veto on packages, but I don't think I'll be stepping to far >outta line here in saying 'just do it' :}. Didn't I already vote on this? I can't remember. I say "just do it", too. cgf
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
On Sun, Jan 13, 2002 at 10:59:41AM -0500, Charles Wilson wrote: > IMO, we should either mandate that: > > name field(s) cannot contain '-' so that we ALWAYS only have three > '-'delimited fields (four in the case of -src packages), or > > setup/upset will always parse from R to L, so the FINAL two '-'delimited > fields will always be considered REL and VER. (or '-src' and REL and VER > in the -src case) This one. I mean, it works, right? Why should we change it to get a less flexible variation? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
Robert Collins wrote: >>Correct -- it does work from R to L. If we cannot depend on this >>behavior, then we must rename the following packages: >> > > Which is one of the implications of the thread where you said > http://cygwin.com/ml/cygwin-apps/2002-01/msg00208.html. Well, consider it a thinko on my part. I was considering "foo-alphabetic-version-release" different from "foo-numeric-version-release" -- but of course, version can have alphabetic characters in it, and my bzip example had numerals in the "extra" field. So both cases really just boil down to: there are four pegs and only three slots. IMO, we should either mandate that: name field(s) cannot contain '-' so that we ALWAYS only have three '-'delimited fields (four in the case of -src packages), or setup/upset will always parse from R to L, so the FINAL two '-'delimited fields will always be considered REL and VER. (or '-src' and REL and VER in the -src case) >>autoconf-devel >>autoconf-stable >>automake-devel >>automake-stable >>tetex-beta >> > > We don't need to rename them immediately, but at the first opportunity > IMO. And setup will need to be geared to handle the rename smoothly as > well (which is on the long term plan anyway). Does '-' sort before or > after '_' ? :]. '-' is 0x2d, '_' is 0x5f So, an empty, fake autoconf-devel "update" and a real autoconf_devel package can be "installed" during the same setup.exe run, and things should just "work". Until setup.exe learns about package conflicts, at which point things become more complicated. > I don't like having fragile behaviour in setup.exe - and this is > potentially fragile - thus the desire to simplify the parsing rules. I think this is a social problem, not a software engineering problem. Either way you are imposing a requirement on packagers: a) only use the last two '-' delimited fields for VER and REL, or b) always use exactly two '-' characters in the package name, between the "name" field and the "VER" field, and between the "VER" field and the "REL" field. (src packages get an extra '-src' tacked onto the end). I think we are already doing (a) -- so why not just make that policy, and go with it...and force upset/setup to obey. > I'm open to commentary - ideally, long term, setup will not care at all > about file naming outside of local scanned installs, and that can be > done via a preprocessor to generate a setup.ini. This however _requires_ > setup.ini to be have more required fields than it does today. > > The other question, is - should '-' or '_' go between name, version and > cygwin-version? '-' definitely. > tetex-beta is more intuitive that tetex_beta, but doing it that way > would require relabelling all the packages globally. Of course a > transition period will exist before setup.exe and upset are changed... > but that could be quite long :]. I don't really see a difference between tetex-beta and tetex_beta. Either is fine with me (actually, I believe it should be just 'tetex'. Doesn't the fact that it has a version number of 20001218 indicate that the source was taken from CVS and is therefore, by definition, "beta"?) -Chuck
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
=== - Original Message - From: "Charles Wilson" <[EMAIL PROTECTED]> Oh, and on voting for this package: IMO just upload it. It's a very core package, required for many apps, and the patches are going into libtool-HEAD. Chris has a veto on packages, but I don't think I'll be stepping to far outta line here in saying 'just do it' :}. Rob
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
- Original Message - From: "Charles Wilson" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, January 13, 2002 6:31 PM Subject: Re: ITP: libtool-devel, libtool-stable, libtool (wrappers) > Robert Collins wrote: > > > >>Okay, I've renamed the devel package: > >> > >>libtool-devel-20010531-6 > >> > > > > that should be libtool_devel-20010531-6 shouldn't it? > > (devel is a flavour and thus part of the name). > > > > I _think_ that the current upset and setup.exe logic actually starts at > > the right and owrks left, so that teh '-''d name will appear in setup > > correctly, but I don't think we should rely on this behaviour. > > > Correct -- it does work from R to L. If we cannot depend on this > behavior, then we must rename the following packages: Which is one of the implications of the thread where you said http://cygwin.com/ml/cygwin-apps/2002-01/msg00208.html. > autoconf-devel > autoconf-stable > automake-devel > automake-stable > tetex-beta We don't need to rename them immediately, but at the first opportunity IMO. And setup will need to be geared to handle the rename smoothly as well (which is on the long term plan anyway). Does '-' sort before or after '_' ? :]. I don't like having fragile behaviour in setup.exe - and this is potentially fragile - thus the desire to simplify the parsing rules. I'm open to commentary - ideally, long term, setup will not care at all about file naming outside of local scanned installs, and that can be done via a preprocessor to generate a setup.ini. This however _requires_ setup.ini to be have more required fields than it does today. The other question, is - should '-' or '_' go between name, version and cygwin-version? tetex-beta is more intuitive that tetex_beta, but doing it that way would require relabelling all the packages globally. Of course a transition period will exist before setup.exe and upset are changed... but that could be quite long :]. Rob
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
Robert Collins wrote: >>Okay, I've renamed the devel package: >> >>libtool-devel-20010531-6 >> > > that should be libtool_devel-20010531-6 shouldn't it? > (devel is a flavour and thus part of the name). > > I _think_ that the current upset and setup.exe logic actually starts at > the right and owrks left, so that teh '-''d name will appear in setup > correctly, but I don't think we should rely on this behaviour. Correct -- it does work from R to L. If we cannot depend on this behavior, then we must rename the following packages: autoconf-devel autoconf-stable automake-devel automake-stable tetex-beta Renaming is a bad thing...are you SURE we shouldn't rely on current behavior? --Chuck
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
- Original Message - From: "Charles Wilson" <[EMAIL PROTECTED]> > > In general, I'd prefer that 'flavours' get indicated in the package name > > (libtool_devel_rc-xxx-x-src.tar.bz2) > > > Okay, I've renamed the devel package: > > libtool-devel-20010531-6 that should be libtool_devel-20010531-6 shouldn't it? (devel is a flavour and thus part of the name). I _think_ that the current upset and setup.exe logic actually starts at the right and owrks left, so that teh '-''d name will appear in setup correctly, but I don't think we should rely on this behaviour. Rob
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
Robert Collins wrote:
> - Original Message -
> From: "Christopher Faylor" <[EMAIL PROTECTED]>
>
>
>>On Wed, Jan 09, 2002 at 01:21:02PM -0500, Charles Wilson wrote:
>>
>>>Preliminary versions are here:
>>>2) is "rc6" okay for a ${REL} number, or should it be a pure number?
>>>(p.s. 'rc' means "robert collins hack" not "release candidate")
>>>
>>upset will do the right thing with it. I just checked. It even seems
>>
> to
>
>>properly support rc6 vs. rc7.
>>
>>I don't have any problems with it but it *is* a departure from the
>>guidelines in http://cygwin.com/setup.html, I believe.
>>
>>I'll let Robert make the executive decision on this one, I think.
>>
>
> I'd prefer a pure number, but if you think folk will get seriously
> confused, then I guess rcx is ok.
>
> In general, I'd prefer that 'flavours' get indicated in the package name
> (libtool_devel_rc-xxx-x-src.tar.bz2)
Okay, I've renamed the devel package:
libtool-devel-20010531-6
Again, it (and the others) are available at
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/libtool/
The setup.hint files are appended below.
I still need some positive votes on this one
--Chuck
libtool (wrappers):
sdesc: "wrapper scripts for libtool-devel and libtool-stable"
ldesc: "GNU libtool is a generic library support script.
Libtool hides the complexity of using shared libraries behind
a consistent, portable interface.
libtool contains libtool-scripts-20010531, and is meant to be
installed alongside libtool-stable (which contains libtool-1.4.2)
and alongside libtool-devel (which contains a hacked
libtool-20010531). It exec's the appropriate version based on
target package heuristics."
category: Devel
requires: ash libtool-devel libtool-stable
libtool-devel
sdesc: "A shared library generation tool"
ldesc: "GNU libtool is a generic library support script.
Libtool hides the complexity of using shared libraries behind
a consistent, portable interface.
libtool-devel contains a modified version of libtool from
cvs (20010531) and supports `transparent' dll-building using
the new auto-import functionality of binutils. libtool-devel
is meant to be installed alongside libtool-stable (which
contains libtool-1.4.2), and alongside the `libtool' package,
which contains wrapper scripts which call the appropriate
`real' libtool, stable or devel, based on target package
heuristics."
category: Devel
requires: cygwin ash automake autoconf libtool
libtool-stable
sdesc: "A shared library generation tool"
ldesc: "GNU libtool is a generic library support script.
Libtool hides the complexity of using shared libraries behind
a consistent, portable interface.
libtool-stable contains libtool-1.4.2, and is meant to be installed
alongside libtool-devel (which contains Robert Collin's hacked-up
version of libtool-1.4, and supports `transparent' dll-building
using the new auto-import functionality of binutils), and alongside
the `libtool' package, which contains wrapper scripts which call
the appropriate `real' libtool, stable or devel, based on target
package heuristics."
category: Devel
requires: cygwin automake autoconf libtool ash
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
- Original Message -
From: "Christopher Faylor" <[EMAIL PROTECTED]>
> On Wed, Jan 09, 2002 at 01:21:02PM -0500, Charles Wilson wrote:
> >Preliminary versions are here:
> >2) is "rc6" okay for a ${REL} number, or should it be a pure number?
> >(p.s. 'rc' means "robert collins hack" not "release candidate")
>
> upset will do the right thing with it. I just checked. It even seems
to
> properly support rc6 vs. rc7.
>
> I don't have any problems with it but it *is* a departure from the
> guidelines in http://cygwin.com/setup.html, I believe.
>
> I'll let Robert make the executive decision on this one, I think.
I'd prefer a pure number, but if you think folk will get seriously
confused, then I guess rcx is ok.
In general, I'd prefer that 'flavours' get indicated in the package name
(libtool_devel_rc-xxx-x-src.tar.bz2)
Rob
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
On Wed, Jan 09, 2002 at 01:21:02PM -0500, Charles Wilson wrote:
>Preliminary versions are here:
>
> http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
>
>See this message (and the thread that follows it) for more info:
>
>http://cygwin.com/ml/cygwin-apps/2001-12/msg00179.html
>
>Although I will support these packages -- as "cygwin applications" I do
>NOT intend to answer "how do I use libtool" questions. I will silently
>drop any message to the cygwin list concerning these packages that I
>believe are *libtool* questions and not *cygwin* questions -- without
>even a "go ask on the libtool mailing list" reply.
>
>1) is the above attitude acceptable? If not, then is anybody else
>willing to take over those packages and "ITP" them?
>2) is "rc6" okay for a ${REL} number, or should it be a pure number?
>(p.s. 'rc' means "robert collins hack" not "release candidate")
upset will do the right thing with it. I just checked. It even seems to
properly support rc6 vs. rc7.
I don't have any problems with it but it *is* a departure from the
guidelines in http://cygwin.com/setup.html, I believe.
I'll let Robert make the executive decision on this one, I think.
cgf
ITP: libtool-devel, libtool-stable, libtool (wrappers)
Preliminary versions are here:
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
See this message (and the thread that follows it) for more info:
http://cygwin.com/ml/cygwin-apps/2001-12/msg00179.html
Although I will support these packages -- as "cygwin applications" I do
NOT intend to answer "how do I use libtool" questions. I will silently
drop any message to the cygwin list concerning these packages that I
believe are *libtool* questions and not *cygwin* questions -- without
even a "go ask on the libtool mailing list" reply.
1) is the above attitude acceptable? If not, then is anybody else
willing to take over those packages and "ITP" them?
2) is "rc6" okay for a ${REL} number, or should it be a pure number?
(p.s. 'rc' means "robert collins hack" not "release candidate")
--Chuck
