apt-get wierdness: when 6 is equal to 9
hello all, problem: two systems with the same sources.list don't know about the same available packages. explanation: i just built a new system, and scp'd over the sources.list file from an older machine. both machines have the same /etc/apt/sources.list: deb ftp://ftp.us.debian.org/debian/ woody main non-free contrib deb-src ftp://ftp.us.debian.org/debian/ woody main non-free contrib deb ftp://non-us.debian.org/debian-non-US woody/non-US main contrib non-free deb-src ftp://non-us.debian.org/debian-non-US woody/non-US main contrib non-free # Security deb http://security.debian.org/debian-non-US woody/non-US main deb-src http://security.debian.org/debian-non-US woody/non-US main deb http://security.debian.org/debian-non-US woody/non-US contrib deb-src http://security.debian.org/debian-non-US woody/non-US contrib # Wine apt-get -b source wine #deb http://gluck.debian.org/~andreas/debian wine main #deb-src http://gluck.debian.org/~andreas/debian wine main yet, on the older machine: satan# dpkg -l *mesa* pn giram-gnome-me none (no description available) pn giram-mesa none (no description available) un mesa-dev none (no description available) ii mesademos 3.4.2-1 Example programs for Mesa (and OpenGL in gen rn mesag-dev none (no description available) pn mesag-glide2-d none (no description available) pn mesag-widgets- none (no description available) pn mesag3 none (no description available) pn mesag3+ggi none (no description available) pn mesag3+ggi-dev none (no description available) un mesag3-glide none (no description available) pn mesag3-glide2 none (no description available) pn mesag3-widgets none (no description available) ii xlibmesa-dev 4.1.0-5 XFree86 version of Mesa 3D graphics library ii xlibmesa3 4.1.0-5 XFree86 version of Mesa 3D graphics library ii xlibosmesa-dev 4.1.0-5 Mesa/XFree86 offscreen rendering library dev ii xlibosmesa34.1.0-5 Mesa/XFree86 offscreen rendering library and on the newer machine: # dpkg -l *mesa* un mesa-dev none (no description available) ii mesademos 3.4.2-1 Example programs for Mesa (and OpenGL in gen ii mesag-dev 3.1-17 Development library for Mesa [libc6]. pn mesag-glide2-d none (no description available) pn mesag-widgets- none (no description available) ii mesag3 3.1-17 A 3-D graphics library which uses the OpenGL pn mesag3+ggi none (no description available) pn mesag3+ggi-dev none (no description available) un mesag3-glide none (no description available) pn mesag3-glide2 none (no description available) pn mesag3-widgets none (no description available) i've typed apt-get clean apt-get update a bunch of times, yet the newer machine doesn't seem to know about the xlibmesa* packages. how can two machines with the exact same sources.list file not know about the same packages? pete -- You may not use the Software in connection with any site that disparages Microsoft, MSN, MSNBC, Expedia, or their products or services ... -- Clause from license for FrontPage 2002
Re: apt-get wierdness: when 6 is equal to 9
once upon a time Peter Jay Salzman [EMAIL PROTECTED] said: problem: two systems with the same sources.list don't know about the same available packages. have you tried running the update selection from dselect. I think the problem is that dpkg only lists the files from the package list when updated via dselect. Or alternativly you could use apt-cache search filename which would use the apt package list. Thanks, Hereward pgp5Uo5B3gG9M.pgp Description: PGP signature
Re: apt-get wierdness: when 6 is equal to 9
begin: Hereward Cooper [EMAIL PROTECTED] quote once upon a time Peter Jay Salzman [EMAIL PROTECTED] said: problem: two systems with the same sources.list don't know about the same available packages. have you tried running the update selection from dselect. I think the problem is that dpkg only lists the files from the package list when updated via dselect. Or alternativly you could use apt-cache search filename which would use the apt package list. Hereward hereward, thanks for the reply. so dselect and apt contain different views of what packages are on the system? just tried it -- i think you're right. imho, this goes beyond inelegance, and borders on a bug that needs to be fixed. it's unthinkable that there are two databases of available packages which are out of sync everytime we choose apt over dselect or dselect over apt. seems like debian should strive to make apt and dselect front ends for the same package management system. :( anyway, your suggestion worked. much thanks! pete -- You may not use the Software in connection with any site that disparages Microsoft, MSN, MSNBC, Expedia, or their products or services ... -- Clause from license for FrontPage 2002
Re: apt-get wierdness: when 6 is equal to 9
once upon a time Peter Jay Salzman [EMAIL PROTECTED] said: just tried it -- i think you're right. imho, this goes beyond inelegance, and borders on a bug that needs to be fixed. it's unthinkable that there are two databases of available packages which are out of sync everytime we choose apt over dselect or dselect over apt. seems like debian should strive to make apt and dselect front ends for the same package management system. :( anyway, your suggestion worked. much thanks! pete I thought it was weird when I first discovered, and even a pain as I couldn't discover why things weren't being listed. I've just got used to using apt-cache now, also because it searches through the describtions and other greater details of the packages. Hereward pgpKjcrvEZus3.pgp Description: PGP signature
Re: apt-get wierdness: when 6 is equal to 9
Peter Jay Salzman([EMAIL PROTECTED]) is reported to have said: begin: Hereward Cooper [EMAIL PROTECTED] quote once upon a time Peter Jay Salzman [EMAIL PROTECTED] said: problem: two systems with the same sources.list don't know about the same available packages. have you tried running the update selection from dselect. I think the problem is that dpkg only lists the files from the package list when updated via dselect. Or alternativly you could use apt-cache search filename which would use the apt package list. Hereward hereward, thanks for the reply. so dselect and apt contain different views of what packages are on the system? just tried it -- i think you're right. imho, this goes beyond inelegance, and borders on a bug that needs to be fixed. it's unthinkable that there are two databases of available packages which are out of sync everytime we choose apt over dselect or dselect over apt. seems like debian should strive to make apt and dselect front ends for the same package management system. :( dselect update will update it's package list 'and' apt-get's list. Odd, but thats the was it works. So dselect update is the one to do. That messed me up as well, until I was informed of it. One of the many pluses of this list. -- A printer consists of three main parts: the case, the jammed paper tray and the blinking red light. ___
Re: apt-get wierdness: when 6 is equal to 9
On Mon, Sep 24, 2001 at 12:21:39PM -0700, Peter Jay Salzman wrote: begin: Hereward Cooper [EMAIL PROTECTED] quote once upon a time Peter Jay Salzman [EMAIL PROTECTED] said: problem: two systems with the same sources.list don't know about the same available packages. have you tried running the update selection from dselect. I think the problem is that dpkg only lists the files from the package list when updated via dselect. Or alternativly you could use apt-cache search filename which would use the apt package list. thanks for the reply. so dselect and apt contain different views of what packages are on the system? Never of what packages are on the system, as far as I know, but perhaps of what packages are available. When apt-get says Reading Package Lists, one of the things it's reading in is dpkg's status file. dpkg and dselect are the original package management systems, more or less. They functioned as a pair: dpkg handled low-level (through dpkg-deb) and medium-level functions, while dselect handled the high-level primary user interface. They are still built from the same source tree, and interface rather closely with each other. Thus, any time you ask dpkg for information, the tool you should expect to have updated it is dselect. apt (originally deity) was written, I think, in large part out of frustration that dpkg/dselect weren't really being developed very actively at the time, and in an attempt to produce a better user interface than dselect. apt also has its own database of available package information, which is in a binary format and much faster than dpkg's text-based available file; in certain situations, which I'll describe in a moment, the two are synchronized. The first and still the most widely-known tool that they produced on top of the libapt-pkg library was apt-get, which was originally basically a debugging tool (the man page describes it as 'the user's back-end to other tools using the APT library'). People started using it as their primary package management front-end, and it ended up being what a lot of people think of as apt. The full-scale dselect replacements are still in development, although some of them are reaching maturity now. What apt *also* succeeded in producing, though, was a much better set of back-ends to dselect. People used to use various things like the ftp, mountable, and cdrom methods: these were all fairly buggy to one degree or another, and apt managed to become a fantastic replacement for all of them. If you use apt that way, through dselect rather than through the incomplete tool apt-get, then you'll find that dpkg's and apt's package databases stay in sync. just tried it -- i think you're right. imho, this goes beyond inelegance, and borders on a bug that needs to be fixed. it's unthinkable that there are two databases of available packages which are out of sync everytime we choose apt over dselect or dselect over apt. Somewhat. Mostly it's a documentation bug. Far too many of the intentions of apt and apt-get are buried in oral history, so people keep asking things like why apt-get doesn't handle recommends and suggests. Far too many people aren't aware, it seems, that you can use dselect and apt simultaneously and have everything work. I wish, though, that apt-get would tell you that it hasn't updated dpkg's database. The 'apt-get update' versus 'dselect update' thing is an incredibly frequently asked question. seems like debian should strive to make apt and dselect front ends for the same package management system. :( They are, more or less. It's just that apt-get is one component of it which doesn't interact with other components at the level you're expecting. I agree that it's confusing. With regard to 'dpkg -l', I'm not sure that it's ever been guaranteed to work the way you want. 'dpkg -l' looks in /var/lib/dpkg/status, while you want information from /var/lib/dpkg/available. Unless something has explicitly synchronized one with the other, you won't get the information you're looking for: it really only displays available package information by luck. If dpkg's database is up to date, you want 'dpkg -p' or similar. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: apt-get wierdness: when 6 is equal to 9
Colin Watson wrote: I wish, though, that apt-get would tell you that it hasn't updated dpkg's database. The 'apt-get update' versus 'dselect update' thing is an incredibly frequently asked question. I wish apt-get update (and more generally the internal update functions that are used by all the apt frontends) would just update the available file for you. It wouldn't be hard to do. I've asked Jason to do this, and IIRC his answer was that he doesn't want to do it because apt maintains more complex package list information than can be represented in dpkg's available file (especially if you have apt set to use multiple distributons at the same time, etc). I find this very unsatisfactory. Yes, generating an available file whenever apt-get update is run may not be technically perfect, and the available file will be missing information apt knows. And yet various things related to the available file not being updated have become very common FAQ's on debian-user and elsewhere. Not having an up-to-date available file breaks a lot of stuff, like: * tasksel * grep-available * dpkg -p That should _just work_ in a high-quality Debian system. I use 'dselect update' myself, and encourage others to do so as well, but some people recoil in fear at the mere mention of dselect. -- see shy jo
Re: apt-get wierdness: when 6 is equal to 9
On September 24, 2001 12:21, Peter Jay Salzman wrote: begin: Hereward Cooper [EMAIL PROTECTED] quote once upon a time Peter Jay Salzman [EMAIL PROTECTED] said: problem: two systems with the same sources.list don't know about the same available packages. have you tried running the update selection from dselect. I think the problem is that dpkg only lists the files from the package list when updated via dselect. Or alternativly you could use apt-cache search filename which would use the apt package list. Hereward hereward, thanks for the reply. so dselect and apt contain different views of what packages are on the system? just tried it -- i think you're right. imho, this goes beyond inelegance, and borders on a bug that needs to be fixed. it's unthinkable that there are two databases of available packages which are out of sync everytime we choose apt over dselect or dselect over apt. seems like debian should strive to make apt and dselect front ends for the same package management system. :( anyway, your suggestion worked. much thanks! pete Afaik, dpkg -l lists only the packages currently installed on the system, or those pending installation. apt-cache search on the other hand searches the apt database for packages that are available for installation. It seems that the packages marked pn are packages that you selected with dselect but never actuallly installed, so it is possible you did not select the same packages for installation on both systems.
Re: apt-get wierdness: when 6 is equal to 9
On Mon, 24 Sep 2001, Joey Hess wrote: maintains more complex package list information than can be represented in dpkg's available file (especially if you have apt set to use multiple distributons at the same time, etc). Yeap, pretty much. I find this very unsatisfactory. Yes, generating an available file whenever apt-get update is run may not be technically perfect, and the Well, here is my rant.. * tasksel * grep-available * dpkg -p That should _just work_ in a high-quality Debian system. You notice that all but dpkg -p were written after APT? They were written with full knowledge that that available file would be inaccurate on 99% of their users systems. They could have been written to use apt-cache on systems that are using APT and this would be a non-problem. In fact, as long as APT is involved the only way to have things just work is to call 'apt-cache dumpavail' and parse that. That function accounts for all variables and presents the same selections that apt-get would see. The reason these tools don't do this is some IMHO mis-guided aversion to assuming APT is being used. After all, there are 2 people out there who don't use it.. Similarly checking if the APT is selected in dselect would be inelegent :P The only way I can see to compromise around this is if someone changes dpkg. Yes, the limited interface to it's methods is unsuitable and must be extended. I suggest that someone cook up a patch to dpkg that changes it to effectively popen the script /usr/lib/dpkg/methods/*/get-available and parses that instead of the available file. Dpkg would also need an way to dump the available file to stdout.. Jason
