Bill Mitchell writes ("Re: ncurses build options..."):
> Should all packages which use common unix commands provided
> by essential digest packages such as cat (textutls), echo
> (shellutls), mkfs (miscutls) declare explicit dependencies on
> the digest packages they need,
N
On Sat, 16 Dec 1995, Ian Jackson wrote:
> Packages which are not essential in and of themselves, but are
> essential merely because they (for example) provide shared libraries
> for others should probably not be marked essential.
>
> The dependency scheme will prevent their premature removal, if
Michael Alan Dorman writes ("Re: ncurses build options..."):
> I forget who holds the keys to the virtual package stuff. Would whoever
> does that please register me an ncurses-dev package, in order to simplify
> this for ncurses as it is for tcl/tk?
You can do this yoursel
Bill Mitchell writes ("Re: ncurses build options..."):
> [ much deleted ]
> It seems to me that the the sequence would go something like this:
> ...
> 4. User says something like "dpkg --remove --force-essential list_of_libs".
No, users should not need to use
Michael Alan Dorman writes ("Re: ncurses build options..."):
> If you mean "during the time it takes them to do the other upgrade" when
> you say "for a bit", then I think you're right. I would like to confirm
> some dpkg behavior, though:
>
On Sat, 9 Dec 1995, David Engel wrote:
> Yes, but not directly. The way I did it was to have tcl74-dev both
> provide and conflict with the virtual package tcl-dev. When tcl75-dev
> comes out, it will do the same thing. This has the advantage of only
> allowing one tcl*-dev package to be install
> > > ncurses-bin-1.9.7a-1.deb will contain the terminfo database manipulation
> > > files. It will depend on ncurses2.
> > It should also depend on libc5.
>
> I've been going on the assumption that since it's dependent upon
> ncurses21, which is in turn dependent on libc5, that dpkg/dselect wou
> > > If the ncurses guys are going to keep blowing off binary compatibility,
> > > then perhaps we should not mess with ncurses at all.
> > I suspect, especially now that we've got the package load spread around
> > more, that Debian will be able to keep up.
> I'm just concerned that this is a l
> On Fri, 8 Dec 1995, Jeff Noxon wrote:
> > I have several months of the ncurses list archived. If anyone is interested
> > in having a copy of the archive, please let me know how to deliver it. :)
>
> How big is it?
1.3MB uncompressed, 450K gzipped.
Jeff
From: Jeff Noxon <[EMAIL PROTECTED]>
> perhaps we should not mess with ncurses at all.
BSD curses does not provide the form and menu interfaces. I am using
these (and possibly the pad and panel interfaces, that's undecided) to
implement a new installation program. It would be a lot more difficult
On Fri, 8 Dec 1995, Jeff Noxon wrote:
> I have several months of the ncurses list archived. If anyone is interested
> in having a copy of the archive, please let me know how to deliver it. :)
How big is it?
> > I suspect that the distributed packaging responsibility will make it
> > unlikely th
On Thu, 7 Dec 1995, David Engel wrote:
> > ncurses2-1.9.7a-1.deb will be the shared library package. It is ncurses2
> > because the major portion of the soname is 2. It will depend on libc5 and
> > ncurses-base.
> This should be ncurses21-* (or ncurses2.1-*). As was already noted,
> the major ver
> On Fri, 8 Dec 1995, Jeff Noxon wrote:
> > If the ncurses guys are going to keep blowing off binary compatibility,
> > then perhaps we should not mess with ncurses at all.
>
> I suspect, especially now that we've got the package load spread around
> more, that Debian will be able to keep up.
I'
On Fri, 8 Dec 1995, Jeff Noxon wrote:
> If the ncurses guys are going to keep blowing off binary compatibility,
> then perhaps we should not mess with ncurses at all.
I suspect, especially now that we've got the package load spread around
more, that Debian will be able to keep up.
> I'm not real
If the ncurses guys are going to keep blowing off binary compatibility,
then perhaps we should not mess with ncurses at all.
I'm not really sure where the big 'push' to move to ncurses came from
(on linux-gcc), and I don't see how it is any better (at this point) than
BSD curses. At least BSD cur
On Thu, 7 Dec 1995, Michael Alan Dorman wrote:
> On Thu, 7 Dec 1995, Ian Jackson wrote:
> > That all sounds reasonable. I take it that the terminfo manipulation
> > programs and the manpages are small enough that having them installed
> > on every system is not a problem (ncurses-runtime will b
> > Also, we need to decide on the package naming conventions for shared
> > library packages.
>
> Well, tell me if this seems to make sense:
>
> ncurses-base-1.9.7a-1.deb will contain a minimum set of terminfo files.
> It depends on nothing.
>
> ncurses2-1.9.7a-1.deb will be the shared librar
On Thu, 7 Dec 1995, roro wrote:
> Contrary to libc5, where the soname is libc.so.5, an therefore
> libc.so.5.0.0 until libc.so.5.2.16 are interchangeble (or was supposed
> to be) ncurses has the soname libncurses.so.2.x. ncurses2 has no meaning
> if the ABI between libncurses.so.2.0 and libncurse
On Thu, 7 Dec 1995, Ian Jackson wrote:
> > ncurses-term-1.9.7a-1.deb will contain the monolithic set of terminfo
> > files. It depends on the lockstep revision of ncurses-base (since we
> > might move a few more things out of term and into base as they seem
> > appropriate -- getting out of syn
> > ncurses-developer:
> > static, debugging and profiling libraries (all in /usr/lib)
>
> Do we really need/want debugging and profiling libraries? No other
> packages currently provide these.
I think the debug libraries, at least, are very useful to have. This
is a package for developers,
On Thu, 7 Dec 1995, Michael Alan Dorman wrote:
> ncurses2-1.9.7a-1.deb will be the shared library package. It is ncurses2
> because the major portion of the soname is 2. It will depend on libc5 and
> ncurses-base.
> Done. Is it necessary or appropriate to have ncurses-dev be
> ncurses2-dev?
Michael Alan Dorman writes ("Re: ncurses build options..."):
> ncurses-term-1.9.7a-1.deb will contain the monolithic set of terminfo
> files. It depends on the lockstep revision of ncurses-base (since we
> might move a few more things out of term and into base as they
On Thu, 7 Dec 1995, Ian Jackson wrote:
> That all sounds reasonable. I take it that the terminfo manipulation
> programs and the manpages are small enough that having them installed
> on every system is not a problem (ncurses-runtime will be an essential
> package).
Actually, they're going into a
Michael Alan Dorman writes ("ncurses build options..."):
> OK, here's what I think I've come up with:
> [snip]
That all sounds reasonable. I take it that the terminfo manipulation
programs and the manpages are small enough that having them installed
on every system
On Thu, 7 Dec 1995, David Engel wrote:
> This will be necessary -- the ncurses developers have already changed
> the shared library version number once since they introduced shared
> library support and have indicated they won't hesitate to do so again.
I wondered at the fact that soname was .2.1.
> OK, here's what I think I've come up with:
>
> ncurses-runtime:
> shared libraries (in /lib)
> looks for files first in /etc/terminfo then /usr/lib/terminfo
> has linux as compiled in fall-back.
> terminfo manipulation programs
> man pages for the pr
OK, here's what I think I've come up with:
ncurses-runtime:
shared libraries (in /lib)
looks for files first in /etc/terminfo then /usr/lib/terminfo
has linux as compiled in fall-back.
terminfo manipulation programs
man pages for the program
27 matches
Mail list logo
