This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFP: texmf


Jan Nieuwenhuizen wrote:
> 
> 520066587150-0001@t-online.de (Jerome BENOIT) writes:
> 
> > I will try to rebuild the tetex-beta package this week-end.
> > To avoid any confusion, I plan to rename it `tetex-bin' as suggested
> > in a previous email.
> 
> Very nice.

Be sure to also create a new 'tetex-beta' package that is empty, but
carries a higher version number than the current tetex-beta package. 
You will also need to inform folks to update 'tetex-beta' FIRST, and
then install 'tetex-bin'

Package renaming is a pain (but sometimes necessary).  Rest assured, you
will see many many FAQs if you *do* rename your package -- make sure the
benefit (reduced confusion?) is worth it.

> Sorry for the vagueness, I only heard some complaints when I sent the
> message.  I've investigated a bit, and pdftex.exe doesn't run when
> libjpeg isn't installed (this was missing from my texmf requires:
> line).  Also, texconfig doesn't run when libncurses5 is not installed,
> while the current default is libcurses6?

libncurses5 package contains only the DLL's so that previously working
executables that depend on those versions don't break (woulda been nice
if I'd known to do that with libpng, right?)

However, NEW package builds will link against libncurses6.

> 
> But I really don't know, there were complaints on the list.  Looking
> at it now, it seems to me that both problems would be fixed by adding
> these to tetex-beta/bin's setup.hint:
> 
>     requires: ash bash cygwin libncurses5 jpeg libpng tiff ncurses sed
>     termcap texmf-base zlib

Nope -- the libpng problem will remain.  That was a goof -- but it
wasn't my fault :-/   The binary interface of libpng changed, but they
didn't bump the dll number -- and I didn't know the binary interface had
changed until it was too late.

> a good idea in any case, but I don't know if there are other problems,
> or what the idea is with the ncurses5/6 libs.

The idea is the same as on linux.  You have runtime shared libs, and
development libs.  The various versions of the runtime libs (DLL's) stay
around "forever" so that old executables will continue to work. 
(libncurses5, libncurses6).  You can have many different sharedlib
packages installed at the same time.  BUT you can only have one
development lib package (import libs)  at a time -- unless you want to
jump thru major hoops.

Therefore, the development lib that is installed at any given time will
induce a dependency on a SPECIFIC runtime-lib version in executables
linked AT THAT TIME.  Currently, the development libs (for [lib]ncurses)
are in the "ncurses" package, and induce dependency on libncurses6.

So: old apps will continue to work, and depend on libncurses5.  New apps
will depend on libncurses6.  Both old apps, new apps, libncurses5, and
libncurses6 can coexist on the same system.

(Libpng is the counterexample.  Call it a screwup)

--Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]