Re: ncurses-1.9.8a ELF release
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't even bother to hash it all out. If you'll answer me a couple of questions, I'll try to come up with a cleaner way that would only require a minimum of changes to dpkg. Here they are: Can, and if so how, dpkg/dselect remove one package and replace it with another in one invocation? Yes. There are some restrictions - most importantly, that the package being replaced be deselected first, or that both the new and old packages be marked essential. Usually dselect and the Conflicts mechanism will handle that bit. You can replace only one package at a time, but an upgrade can replace one other package as well as the previous version of the package being installed. Does dpkg/dselect allow a package to be upgraded or replced with another and then left in an unconfigured state? Yes, it does. This is necessary to avoid having ordering restrictions on the bulk transfer part of the installation. Basically, what I'm concerned with is the time between an old package's postrm script being called and any new package's postinst being called. I think you need to read project/standards/maintainer-script-args.txt - it describes in some detail exactly what happens when and which scripts get called. Ian.
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, at some point in the future, I know that libfoo.so.x.y whill no longer be needed for any number of reasons. What I'd like to be able to do after dpkg is done upgrading foo-n with foo-m, removing foo-n completely or replacing foo-n with bar-p, is have libfoo.x.y deleted, if and only if, no remaining package claims to own libfoo.x.y. Can this be done, and if so, how? Claims to own? Do you mean claims to need ? No! By own, I mean that the file belongs to a package and shows up when running dpkg -L on that package. I'm assuming that dpkg's normal dependency checking won't allow the package to be removed while others still depend on/need it. Ah, right. In that case, the answer is that dpkg does this already - but it does it (removes the old libfoo.x.y) before th the postinst runs. Plain files are oonly in one package at once. What I meant was that, supposing you upgrade libc5 from 5.0.9-1 to 5.2.7-1, you find that the old package contains libc.so.5.0.9 and the new libc.so.5.2.7. The link needs to be changed to point at 5.2.9 when *both* files are available, surely, as otherwise it will point into nowhere for a bit ? 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 getting any clearer ? :-/ Ian.
Re: ncurses-1.9.8a ELF release
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 getting any clearer ? :-/ 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't even bother to hash it all out. If you'll answer me a couple of questions, I'll try to come up with a cleaner way that would only require a minimum of changes to dpkg. Here they are: Can, and if so how, dpkg/dselect remove one package and replace it with another in one invocation? Does dpkg/dselect allow a package to be upgraded or replced with another and then left in an unconfigured state? Basically, what I'm concerned with is the time between an old package's postrm script being called and any new package's postinst being called. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: ncurses-1.9.8a ELF release
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, at some point in the future, I know that libfoo.so.x.y whill no longer be needed for any number of reasons. What I'd like to be able to do after dpkg is done upgrading foo-n with foo-m, removing foo-n completely or replacing foo-n with bar-p, is have libfoo.x.y deleted, if and only if, no remaining package claims to own libfoo.x.y. Can this be done, and if so, how? Claims to own? Do you mean claims to need ? And is foo-n the package name, or is foo the package name and n the version ? Sorry, I'm still confused. What I meant was that, supposing you upgrade libc5 from 5.0.9-1 to 5.2.7-1, you find that the old package contains libc.so.5.0.9 and the new libc.so.5.2.7. The link needs to be changed to point at 5.2.9 when *both* files are available, surely, as otherwise it will point into nowhere for a bit ? Ian.
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, at some point in the future, I know that libfoo.so.x.y whill no longer be needed for any number of reasons. What I'd like to be able to do after dpkg is done upgrading foo-n with foo-m, removing foo-n completely or replacing foo-n with bar-p, is have libfoo.x.y deleted, if and only if, no remaining package claims to own libfoo.x.y. Can this be done, and if so, how? Claims to own? Do you mean claims to need ? No! By own, I mean that the file belongs to a package and shows up when running dpkg -L on that package. I'm assuming that dpkg's normal dependency checking won't allow the package to be removed while others still depend on/need it. And is foo-n the package name, or is foo the package name and n the version ? Foo and bar are package names. N, m and p are different versions and/or revisions. Sorry, I'm still confused. What I meant was that, supposing you upgrade libc5 from 5.0.9-1 to 5.2.7-1, you find that the old package contains libc.so.5.0.9 and the new libc.so.5.2.7. The link needs to be changed to point at 5.2.9 when *both* files are available, surely, as otherwise it will point into nowhere for a bit ? 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: As far as I can see we have three kinds of shared library: 1. Packages like X or mkfs or what have you, where it doesn't matter if the library link is missing momentarily, or even if it's absent while the package is in a broken state according to dpkg. 2. Packages like the libc or ncurses, where we can't leave it broken even for an instant without risking an unrecoverable system. 3. The shared library is part of the same package as the executables and is version-specific - it's just there to save disk space and memory, and furthermore this is a critical package which we can't leave broken. AFAIK only dpkg falls into category 3. Lots of things fall into category 1, but they can do without special handling. Category 1 needs the link to be updated *with both libraries present*, am I right ? David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: ncurses-1.9.8a ELF release
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 running programs when the package is being upgraded, but there is no provision for deleting the files when the package is removed. Again, I'd like to hear Ian Jackson's thoughts on adding special installation support for shared libraries to dpkg. Ian Jackson, are you there? I'd *really* like to hear your opinions on this. Yes, I'm here. Sorry, I haven't been reading this mail for a few days and I'm noow catching up on a 400-message backlog. OK, I know what that's like. As far as I can see we have three kinds of shared library: 1. Packages like X or mkfs or what have you, where it doesn't matter if the library link is missing momentarily, or even if it's absent while the package is in a broken state according to dpkg. 2. Packages like the libc or ncurses, where we can't leave it broken even for an instant without risking an unrecoverable system. 3. The shared library is part of the same package as the executables and is version-specific - it's just there to save disk space and memory, and furthermore this is a critical package which we can't leave broken. AFAIK only dpkg falls into category 3. Lots of things fall into category 1, but they can do without special handling. Right. Category 2 is mainly what I'm interested in. Category 1 needs the link to be updated *with both libraries present*, am I right ? No, I don't think so. For these, it should be sufficient to just do it in the postinst script. Could you take a good look at maintainer-script-args.txt in project/standards, and consider what extra functionality you'd like me to include in dpkg ? I've been looking at it off and on for the last few days now and I still don't know if I can do what I want to do. Let me try presenting the problem differently and you tell me if and how it can be done. 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 be needed for any number of reasons. What I'd like to be able to do after dpkg is done upgrading foo-n with foo-m, removing foo-n completely or replacing foo-n with bar-p, is have libfoo.x.y deleted, if and only if, no remaining package claims to own libfoo.x.y. Can this be done, and if so, how? David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: ncurses-1.9.8a ELF release
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 running programs when the package is being upgraded, but there is no provision for deleting the files when the package is removed. Again, I'd like to hear Ian Jackson's thoughts on adding special installation support for shared libraries to dpkg. Ian Jackson, are you there? I'd *really* like to hear your opinions on this. Yes, I'm here. Sorry, I haven't been reading this mail for a few days and I'm noow catching up on a 400-message backlog. As far as I can see we have three kinds of shared library: 1. Packages like X or mkfs or what have you, where it doesn't matter if the library link is missing momentarily, or even if it's absent while the package is in a broken state according to dpkg. 2. Packages like the libc or ncurses, where we can't leave it broken even for an instant without risking an unrecoverable system. 3. The shared library is part of the same package as the executables and is version-specific - it's just there to save disk space and memory, and furthermore this is a critical package which we can't leave broken. AFAIK only dpkg falls into category 3. Lots of things fall into category 1, but they can do without special handling. Category 1 needs the link to be updated *with both libraries present*, am I right ? If you naively install the libraries under their real names in the package, then there will only be a brief period while dpkg is running when both libraries are present, and there's not currently any way to get a script or anything run there. You could possibly fudge something up with the maintainer scripts, and putting the files in the package under different names. Could you take a good look at maintainer-script-args.txt in project/standards, and consider what extra functionality you'd like me to include in dpkg ? One possibility is an extra maintainer script called in the guts of dpkg's processing - if you like that idea, remember to think about error handling ... Ian.
Re: ncurses-1.9.8a ELF release
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*.so are in the runtime package. They should be in the -dev package. The shared libraries for form, menu and panel are in /lib. They should probably be in /usr/lib unless and until a boot-critical program needs them /lib. The symlink for libcurses.a is wrong. It should point to libncurses.a. There is no symlink for libcurses.so. There should be one in the -dev package. 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 running programs when the package is being upgraded, but there is no provision for deleting the files when the package is removed. Again, I'd like to hear Ian Jackson's thoughts on adding special installation support for shared libraries to dpkg. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: ncurses-1.9.8a ELF release
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 libraries for form, menu and panel are in /lib. They should probably be in /usr/lib unless and until a boot-critical program needs them /lib. Well, since _nothing_ needs them right now...Done. The symlink for libcurses.a is wrong. It should point to libncurses.a. Done. 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? 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 running programs when the package is being upgraded, but there is no provision for deleting the files when the package is removed. Again, I'd like to hear Ian Jackson's thoughts on adding special installation support for shared libraries to dpkg. For the moment I guess I'll re-rename them in the prerm. Mike. -- I'm a dinosaur. Somebody's digging my bones.
Re: ncurses-1.9.8a ELF release
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 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 (incomplete/buggy?) termcap interface. 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 running programs when the package is being upgraded, but there is no provision for deleting the files when the package is removed. Again, I'd like to hear Ian Jackson's thoughts on adding special installation support for shared libraries to dpkg. For the moment I guess I'll re-rename them in the prerm. Ian Jackson, are you there? I'd *really* like to hear your opinions on this. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: ncurses-1.9.8a ELF release
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 (incomplete/buggy?) termcap interface. That's what I remembered, and I'm going to leave it out. It won't be a big deal to put in if it turns out we're both mistaken. Jeff -- I would be more likely to consider this if we had some experimental evidence regarding whether your average autoconf'd program will DTRT. I'm willing to try it myself with ncftp and anything else I compile that uses ncurses, but I don't think that's a big enough sample. For the moment I guess I'll re-rename them in the prerm. Ian Jackson, are you there? I'd *really* like to hear your opinions on this. I still want to get -2 out today because there are a few small but potentially significant problems in -1. Mike. I'm a dinosaur. Somebody's digging my bones.
Re: ncurses-1.9.8a ELF release
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? On a disk tight system I don't want to have to install -dev just to run some packages built on ncurses. Let me know if I what I'm missing here. Under ELF, the .so (rather than .so.X.X.X) file is _only_ used for compile/link. Some portion of the .X.X.X segment is encoded into the executable (as the soname), and _that_ (.so.X, say) is what the executable looks for. So (get it?), the .so files are only needed in -dev. Mike. -- I'm a dinosaur. Somebody's digging my bones.
Re: ncurses-1.9.8a ELF release
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 provide, the shared libraries? And the symlinks are used by ld.so, no? On a disk tight system I don't want to have to install -dev just to run some packages built on ncurses. Let me know if I what I'm missing here. Mike already did a good job of answering this. The only thing I'll add is that ldconfig manages any links needed by ld.so. For run-time packages, all you have to do is install the libfoo.so.X.Y.Z files and ldconfig will do the rest. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
