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.)
RedHat:
ncurses
so's and ld-conf-style so-links, utility programs,
man(1) pages for utils, term(5), terminfo(5), term(7)
terminfo database
ncurses-devel
static libs, developmen links for so's (e.g. import
libs in windows parlance), sources for the test programs,
man(3) pages
ncurses4
contains old so's.
Mandrake:
libncurses5-....,rpm
contains only the .so's and ld.conf-style so-links
(but NOT the development links)
ncurses-devel
contains static libs, headers, the man(3) pages,
sources for the test programs, development links for
the shared libs
ncurses
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)
I have:
libncurses6
contains only the shared libraries
ncurses
contains everything in Red Hat's ncurses-devel and
ncurses RPMS, minus the terminfo database
terminfo
contains the terminfo database
libncurses5
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
capabilities.
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.
--Chuck