Re: pkg_add vs. cvs -up, and pkg_check telling me about unknown files & directories
On Wed, Feb 25, 2015 at 05:35:43PM +0900, Joel Rees wrote: > So the file system is the package management system? File system == base system + xenocara + pkg system + user files We now have mostly accurate information for all of these, which is what the end run of pkg_check tries to do. > Is, perhaps, pkg_check trying to do too many things, maybe? Nah, it's just not finished yet, but we don't have any tools being able to clean up the base system. And since there is stuff in /etc that actually belongs to the pkg system, I see no way around that. Also, assuming you only have base systems and packages installed, knowing when to remove old shared libraries is something we have information for... So, yeah, it's the correct place to do things. You can't do it without having all the packaging information.
Re: pkg_add vs. cvs -up, and pkg_check telling me about unknown files & directories
On Wed, Feb 25, 2015 at 12:17 AM, Marc Espie wrote: > For instance, here's what pkg_check says on a somewhat older machine > I haven't cleansed in a while, along with my commentary. > > (warning, long post). Indeed. > Like they said, the devil lies in the details. There are about 10 (or more) > special cases I haven't taken care of yet... > > Not found: > /.install_started > (fun, old bsd.rd stuff) > /basename.core > (fun, a core) > /bin/badsh > (okay, my bad, pie fuckup) > /bin/rcp > /bin/rmail > /bin/sum > (now, those are old things) > /boot Okay, I think I see that I don't need to worry about the unknown files/directories it reports. > (that one should be an exception) > /bsd > /bsd.120320 > /bsd.120828 > /bsd.120927 > /bsd.121106 > /bsd.130423 > /bsd.130430 > /bsd.130514 > /bsd.130711 > /bsd.130723 > /bsd.131015 > /bsd.131113 > /bsd.131210 > /bsd.140715 > /bsd.150121 > /bsd.rd > /bsd.sp > (should I ignore everything as bsd* ?) Depends on the purpose, I'd guess. > /dos Is that a mount point in your system, too? > /etc/X11/app-defaults/Beforelight > [...] So the file system is the package management system? Is, perhaps, pkg_check trying to do too many things, maybe? Anyway, now I'm pretty sure I can safely assume that, since pkg_info is working again, I don't have to scratch my ports partition and re-populate it from scratch. Still not sure why pkg_info and pkg_add were geting stuck until I used pkg_check. Thanks, Joel Rees
Re: pkg_add vs. cvs -up, and pkg_check telling me about unknown files & directories
On Sun, Feb 22, 2015 at 10:46:36PM +0900, Joel Rees wrote: > I then tried using pkg_check to see if I could clear whatever I had > done, and it tells me about unknown directories and files, a long list > of files and directories which should have nothing to do with > packages, I think, including such things as /boot, /bsd, about 30 > files in /etc, the pkg_check_out.text I produced in my /root directory > to try to understand the output and a bunch of other stuff. It does > not output my entire file system tree. [...] > Marc or anyone care to enlighten me on what the output from pkg_check > is supposed to mean? (I'm thinking it may have something to do with > mtree, but I'm not remembering what to look at for that.) That part of pkg_check is not totally finished. It does check the full fs, and remove anything it knows about (thanks to the various locate(8)dbs and to /var/db/pkg) plus a few well known positives, but I haven't gotten around to teaching it the few important exceptions that remain. And also, some packages create "ghost" data. On my todo list to register properly with pkgs. You can usually use it to remove some older stuff, older gcc and perl modules that no longer exist in base show up as a sore thumb. I guess THAT specific functionality is mostly developer material for now. When you already know the system well, it can be very useful.
Re: pkg_add vs. cvs -up, and pkg_check telling me about unknown files & directories
Joel Rees writes: > I recently tried, for fun, or because I wasn't thinking, I'm not sure > which, doing a cvs -up in /usr/ports. It told me "P" or "U" for > archivers/cabextract, net/isc-bind, and www/drupal6/views, none of > which should be installed on my system. (I don't remember which was P > and which U.) Since they are not supposed to be installed, I did not > run make in any of their directories in /usr/ports. cvs operations have little to do with the packages you have installed / ports you have built. man cvs | less +'/ U ' pkg_check is known to report false positives. I doubt there is enough data to tell whether your pkg_add / pkg_info glitches are real issues or just local, transient errors. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
pkg_add vs. cvs -up, and pkg_check telling me about unknown files & directories
I recently tried, for fun, or because I wasn't thinking, I'm not sure which, doing a cvs -up in /usr/ports. It told me "P" or "U" for archivers/cabextract, net/isc-bind, and www/drupal6/views, none of which should be installed on my system. (I don't remember which was P and which U.) Since they are not supposed to be installed, I did not run make in any of their directories in /usr/ports. I tried to use pkg_info and pkg_add -n to figure out if they were installed after all, and pkg_add started hanging, and then pkg_info started hanging. I then tried using pkg_check to see if I could clear whatever I had done, and it tells me about unknown directories and files, a long list of files and directories which should have nothing to do with packages, I think, including such things as /boot, /bsd, about 30 files in /etc, the pkg_check_out.text I produced in my /root directory to try to understand the output and a bunch of other stuff. It does not output my entire file system tree. After using pkg_check several times, pkg_add and pkg_info are no longer hanging. And pkg_add -u seems to do what it is supposed to do. Marc or anyone care to enlighten me on what the output from pkg_check is supposed to mean? (I'm thinking it may have something to do with mtree, but I'm not remembering what to look at for that.) Joel Rees
