David Engel writes ("Re: ncurses-1.9.8a ELF release"):
> Slowly. I've been trying to better understand how dpkg works and find
> a way to do what I want with the current behaviour. The only way I've
> come up with is rather ugly and probably error prone so I haven&#
> > Now I'm confused. That part of my message was in reference to your
> > comment on category 1 packages where you contradicted yourself. Did
> > you mean category 2 instead? Here is the relevant section from your
> > earlier message:
>
> Yes, I did mean categoory 2 instead.
>
> Is this getti
> > > Let's say I have a package named foo-n with a shared library in it
> > > named libfoo.so.x.y that, at least for the time being, must always be
> > > available by that name, even while dpkg is moving things around. Now,
> > > at some point in the future, I know that libfoo.so.x.y whill no lon
> > Let's say I have a package named foo-n with a shared library in it
> > named libfoo.so.x.y that, at least for the time being, must always be
> > available by that name, even while dpkg is moving things around. Now,
> > at some point in the future, I know that libfoo.so.x.y whill no longer
> >
David Engel writes ("Re: ncurses-1.9.8a ELF release"):
> Let's say I have a package named foo-n with a shared library in it
> named libfoo.so.x.y that, at least for the time being, must always be
> available by that name, even while dpkg is moving things around. Now,
>
> David Engel writes ("Re: ncurses-1.9.8a ELF release"):
> > [ and earlier: ]
> > > > The runtime package installs the shared libraries as lib*.so.3.0.new
> > > > and then renames them to lib*.so.3.0 in the postinst script. This is
> > > > fi
David Engel writes ("Re: ncurses-1.9.8a ELF release"):
> [ and earlier: ]
> > > The runtime package installs the shared libraries as lib*.so.3.0.new
> > > and then renames them to lib*.so.3.0 in the postinst script. This is
> > > fine for not disturbing ru
> >> The symlinks for lib*.so are in the runtime package. They should be
> >> in the -dev package.
> >
> >Makes sense. Done.
>
> It doesn't make sense to me. I thought that the runtime package would
> include all of the shared libraries that other programs might need.
> Isn't that what lib*.so
On Sun, 10 Dec 1995, Chris Fearnley wrote:
> It doesn't make sense to me. I thought that the runtime package would
> include all of the shared libraries that other programs might need.
It does.
> Isn't that what lib*.so provide, the shared libraries? And the
> symlinks are used by ld.so, no? O
On Sun, 10 Dec 1995, David Engel wrote:
> I have been told that this is undesirable for some autoconfed programs
> with emacs being the most notable example. I don't remember all of
> the details but it has to do with forcing autoconf to use the
> curses/termlib interface to ncurses instead of the
'Michael Alan Dorman wrote:'
>
>> The symlinks for lib*.so are in the runtime package. They should be
>> in the -dev package.
>
>Makes sense. Done.
It doesn't make sense to me. I thought that the runtime package would
include all of the shared libraries that other programs might need.
Isn't tha
> > There is no symlink for libcurses.so. There should be one in the -dev
> > package.
>
> OK. Jeff Noxon mentioned that a link for libtermcap.so might also be in
> order---thoughts?
I have been told that this is undesirable for some autoconfed programs
with emacs being the most notable exampl
On Sun, 10 Dec 1995, David Engel wrote:
> The -dev package provides virtual ncurses-dev package but it also
> needs to conflict with it.
Oops. You told me that. Done.
> The symlinks for lib*.so are in the runtime package. They should be
> in the -dev package.
Makes sense. Done.
> The shared
> Having said all that, there's the .changes file for 1.9.8a:
Hi Mike,
I got your latest packages from ftp.pixar.com. All in all, things
look good. Here are my initial findings.
The -dev package provides virtual ncurses-dev package but it also
needs to conflict with it.
The symlinks for lib*
14 matches
Mail list logo
