Mail Archives: cygwin-apps/2001/09/19/22:48:43
Robert Collins wrote:
> Should the man pages be in with the .dlls? Or at least the end user ones
> that refer to setting TERM etc?
I was just following the lead of the other distros RPMS. Besides, what
you suggest would cause conflicts -- both libncurses5 and libncurses6
would contains these man pages, leading to ordering problems with
upgrades (Or, forcing me to update libncurses6 MERELY because
libncurses7 is coming out -- update 6 so NOT include those man pages.
But then you STILL have ordering problems.)
so's and ld-conf-style so-links, utility programs,
man(1) pages for utils, term(5), terminfo(5), term(7)
static libs, developmen links for so's (e.g. import
libs in windows parlance), sources for the test programs,
contains old so's.
contains only the .so's and ld.conf-style so-links
(but NOT the development links)
contains static libs, headers, the man(3) pages,
sources for the test programs, development links for
the shared libs
contains the utility programs, and the man pages (for
those programs only, term(5), terminfo(5), term(7))
the terminfo database, and a few other docs
(NOTE that I was wrong earlier; Corinna suggested naming my libncursesX
packages as ncursesX -- I replied that Red Hat didn't do that. However,
Red Hat *does* do that. Mandrake uses the 'lib' nomenclature)
contains only the shared libraries
contains everything in Red Hat's ncurses-devel and
ncurses RPMS, minus the terminfo database
contains the terminfo database
contains old shared libraries
> Could the static library and header tarball be called ncurses-dev-5.2-6
> ? (I hope the reason is obvious :})
The way I have it, the ncurses package contains the devel stuff, but
also the utility programs, generic documentation, and utility man(1)
pages. I thought about splitting my new ncurses into an 'ncurses' and
'ncurses-devel' package -- but decided to let necessity be my guide --
only split if there is a *compelling* reason.
terminfo -- fork for ease of update
libncursesX -- necessity for back compatibility given setup.exe's
everything else goes in ncurses.
Basically, I don't *really* want to start a trend of splitting all the
packages into oodles of itty bitty foo, foo-devel, foo-doc, foo-client,
foo-server, packages. Necessity drives me this far -- but I don't want
to go further just for the hell of it.
> I don't think the linktime requirement is a biggy. Some folk will
> complain "I updated and now my *** app won't link". Other will read the
> README :|. No way around it though - with one exception.
> We could release the cygwin binutils with --auto-import on by default.
> (Without propogating that change upstream).
That's up to Chris. Having just pestered him to release a new version
with Ralf's fix, I'd prefer to wait before (a) bugging him again (b)
slamming the mirrors with Yet Another Update. Besides, there's a few
more items on the TODO list for binutils; it'd be nice to push some of
that thru before the next binutils rev.
- Raw text -