public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
* libtool packaging errors
@ 2008-04-03 13:29 Christopher Faylor
  2008-04-03 22:40 ` Charles Wilson
  0 siblings, 1 reply; 2+ messages in thread
From: Christopher Faylor @ 2008-04-03 13:29 UTC (permalink / raw)
  To: cygwin-apps

*** upset: release/libtool/libtool1.5/setup.hint:11: unknown key 'conflicts: libtool2.2'

I've commented out the offending line.

cgf

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: libtool packaging errors
  2008-04-03 13:29 libtool packaging errors Christopher Faylor
@ 2008-04-03 22:40 ` Charles Wilson
  0 siblings, 0 replies; 2+ messages in thread
From: Charles Wilson @ 2008-04-03 22:40 UTC (permalink / raw)
  To: CygWin-Apps

Christopher Faylor wrote:
> *** upset: release/libtool/libtool1.5/setup.hint:11: unknown key 'conflicts: libtool2.2'
> 
> I've commented out the offending line.

Sorry. I remembered (from the last time I looked at the setup source 
code) that its lexer understands conflicts:, so I included it.

As it happens, that's about the ONLY thing that understands the 
conflicts: keyword.  Setup will properly parse and store the information 
within the object representation of the ini file, so that 
myPkgVerNode->conflicts() will return the correct information.

But setup's installer does not use the information.  And as we 
discovered, upset chokes on it as well.

So, any suggestions? These two packages -- libtool1.5 and libtool2.2 -- 
DO conflict.  Ordinarily, we'd just have:

libtool-{1.5.x|2.2.x}
libltdl3-1.5.x
libltdl7-2.2.y

and it would "just work"(tm) like other packages do. However, this 
'numbered' approach to the libtool packages (as opposed to the libltdl 
ones) was chosen for three reasons:

1) there is hope that in the future, we can have simultaneous parallel 
installations, just like ac-2.13/ac-2.61 and am-x.y.  We're not there 
yet, tho.

2) legacy from the old libtool-stable/libtool-devel split

3) Three years ago (when libtool-2.0 was gonna be released Real Soon 
Now, We Promise), I had intended to continue maintaining parallel 
releases of 1.5.x and 2.0.x, and wanted separate prev/test/curr choices 
for each development stream.  You can't do that if both 1.5-derived and 
2.2-derived are all named "libtool"

Here are the choices as I see them (given that items #1 and #2 above are 
no longer operative)

A) give up on item #3, and consolidate all libtoolx.y into a new 
"libtool" package. Eventually, 1.5.x releases will not be easily 
accessible from setup, because the prev/curr/test 'slots' will all be 
2.2-related.

B) Leave stuff alone, and just rely on savvy users reading the 
Announcements, which encourage them to "uninstall libtool1.5 before 
installing libtool2.2".  If they don't do this, the "fix" is simple:
   i) uninstall both libtool1.5 and libtool2.2
   ii) reinstall the desired version

C) Fix setup to understand conflicts:, and update upset to allow such 
things.
   i) I don't know how to do this
   ii) Folks who do have more important things on their minds right now, 
with Corinna's 1.7 proposal

Comments?

--
Chuck

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-04-03 22:40 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-04-03 13:29 libtool packaging errors Christopher Faylor
2008-04-03 22:40 ` Charles Wilson

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