I have sent this with a modified subject. It seems yahoo didn't like, so I am resending with the unchanged thread subject, to test. Apologies if two posts appear.
On 29-10-2014 07:26, Richard Melville wrote: > On 29 October 2014 07:32, Chris Staub <[email protected]> wrote: > >> On 10/28/14 23:26, JUAN CARLOS SANHUEZA CID wrote: >> >>> Hi friend >>> >>> How to unistall mysql server from lfs / blfs system ? >>> Usually by using a package manager to track what was installed, then >> using that package manager to uninstall. If you didn't use one, you'll just >> need to manually track down every installed file. One way might be to >> install it into a DESTDIR to see what files it installed. Perhaps installing your suggestions of package logger, it would be easier to remove it. > Or a package logger; Paco (now Porg) still works for me > http://porg.sourceforge.net/ > > It's small, light, easy to use and it just works -- I can't recommend it > enough. If you use it from the moment you start an LFS build you will have > a complete log of all packages (complete with their associated files) on > the system, with the added benefit of ease of package removal and > updating. If you forget to log a package it can be logged retroactively. > The man page can be seen here http://linux.die.net/man/8/paco It took most part of the day, a lot because I wanted to do a porg and a paco install scripts allowing to use the not yet installed binary to make a DESTDIR install of itself *and* "make DESTDIR=$DESTINODIR logme" Second thing: I had dhcpcd-6.6.0 and firefox-33.0.2 to update, and wanted to use both paco and porg, in order to compare one with the other. Short answer to Juan Carlos: Why do you need to remove mysql? Just removing the initscripts is not enough? If you really need to remove it, install porg, then use porg to reinstall mysql, then use porg to remove mysql. Before or after that, remember to remove the initscripts as Bruce told already. Now, back to Richard. I like very much paco and it can really remove almost without problems packages installed with it. But not always. Unless you use something different from me, it simply does not work for some packages. The ones by mozilla are always wrong for me. I install firefox with: SOURCEDIR is what the name says. EXTDIR=/usr/lib/firefox-33.0.2/browser/extensions PACO_PACKAGE=firefox-33.0.2 INSTALLCOMMAND="make -f client.mk install INSTALL_SDK= && ln -sfvn ../../mozilla/plugins /usr/lib/firefox-33.0.2/browser && install -v -m644 $SOURCEDIR/firefox-33.0.2-pt-BR.xpi \ ${EXTDIR}/langpack-pt-BR@${PACKAGE_NAME}.mozilla.org.xpi" paco -lp $PACO_PACKAGE "$INSTALLCOMMAND" With porg, just s/paco/porg/. First problem (also occurring with porg) is that it considers almost 20MB of files created in the source directory as part of the installed files. After a package (present case is firefox-33.0.2) installed, I run: $ paco -sMFCndd firefox-33.0.2 20M [ ] 15 [ ] ( 1) 29-Oct-2014 18:14 firefox-33.0.2 This is completely wrong. Installed 20MB and 15 files, where one is shared as the following command demonstrates: $ paco -fc firefox-33.0.2 firefox-33.0.2: /usr/bin/firefox It is shared with previous version of firefox, although the new version overwrote it to point to the new version. $ du -sch /usr/lib/firefox-33.0.2 `paco -f firefox-33.0.2 | grep fernando | xargs echo` /usr/bin/firefox ... 119M total $ du -sch /usr/lib/firefox-33.0.2 /usr/bin/firefox99M /usr/lib/firefox-33.0.2 0 /usr/bin/firefox 99M total Almost all of the 20M that paco informs are in the source directory. If I move out the source directory, update firefox-33.0.2 log, using: # paco -u firefox-33.0.2 then $ paco -sMFCndd firefox-33.0.2 408k [19M] 3 [12] ( 1) 29-Oct-2014 18:14 firefox-33.0.2 Now, the size of installed files is 408k, 19M are missing, only 3 files installed, 12 files missing, still 1 shared file. List of installed files: $ paco -fy firefox-33.0.2 firefox-33.0.2: /usr/bin/firefox -> /usr/lib/firefox-33.0.2/firefox /usr/lib/firefox-33.0.2/browser/extensions/[email protected] /usr/lib/firefox-33.0.2/browser/plugins -> ../../mozilla/plugins It is obvious that this is wrong. Consequently, if you try to remove using paco -r firefox-33.0.2 only two file will be removed (shared files are not removed) so you are left with almost all firefox in the HD, except for a .xpi langpack and a symlink to mozilla plugins, the only ones removed. The good news is that porg seems to work almost correctly, taking into account all installed files. I checked using find an comparing with porg -f. I say almost correctly, because it also has the same defect of paco, considering exactly the same 12 files in the source directory as installed files. And there are regressions (at least I think they are): {{{ Disabled the options for removing shared files when uninstalling a package, both in porg and grop. Now shared files are never removed, as it ougth to be. [Paco never removed a shared file during the time I use it.] Disabled listing of missing and shared files. {Very bad: gave me a lot of information.] Simplification of the GUI. {Did not test.] Simplification of the package database. No need to update it anymore. [Very bad, see below.] Major code enhancements and cleanup. Additionally, all changes documented in the Changelog. }}} Due to some of these changes, less information than paco gives, the more complete output I could find was: $ porg -sFdd dhcpcd-6.6.0 firefox-33.0.2 350k 15 10/29/14 15:57 dhcpcd-6.6.0 118M 54 10/29/14 18:20 firefox-33.0.2 For dhcpcd, it should give 384k (interesting, paco gives that value), but this is not big deal, as the files are really the ones installed (/etc/dhcpcd.conf is in the DESTDIR, but not in the actual install, because was installed before by a previous version). But firefox has wrong size and number of files. It should be 100M, the 18M are those files in the source directory (12 files). And the lack of the update command means that they will be there as if installed, even after the source directory is removed. Bottom line: I was going to disprove porg and keep paco, but because at least porg doesn't seem to miss installed files (although sometimes some of them are not there anymore), it is more useful for eventual removal of the package. However, sizes and number of installed files are not reliable enough for using in the BLFS statistics. When paco works, results seem better. -- []s, Fernando -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
