From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B050B1389E2 for ; Thu, 25 Dec 2014 11:04:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0B325E0A5B; Thu, 25 Dec 2014 11:04:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 74773E0A59 for ; Thu, 25 Dec 2014 11:04:23 +0000 (UTC) Received: from [192.168.100.192] (67-203-132-147.static-ip.telepacific.net [67.203.132.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 9C3643404F7 for ; Thu, 25 Dec 2014 11:04:22 +0000 (UTC) Message-ID: <549BEF34.90603@gentoo.org> Date: Thu, 25 Dec 2014 03:04:20 -0800 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] Re: [RFC] New file layout for PKGDIR and binhosts References: <549A1C31.8040500@gentoo.org> <549A4C25.9050000@gentoo.org> <549A75C5.70600@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 618c513a-7e85-4bc5-9e35-b229df27d45d X-Archives-Hash: d8e4c572c0b9bece4a6a5a500c8907da On 12/25/2014 02:03 AM, Duncan wrote: > Zac Medico posted on Wed, 24 Dec 2014 00:13:57 -0800 as excerpted: > >>> If there were some way to >>> get all the info for the binpkgs into one file (so it could be run on >>> cron or something), this could mean that I'd only have to do one file >>> request for all that metadata and would be much quicker than inspecting >>> all those files. >> >> That's what $PKGDIR/Packages is. > > This is a good excuse to ask a question that has bothered me for some > time, plus make a request for the new eclean-pkg replacement... > > Normally I like to keep several old binpkgs around for troubleshooting > reference or quick-install, but the combined set of kde packages, for > instance, can get pretty big, and with monthly iterations, they build up > pretty fast. > > But eclean-pkg doesn't have an easy way to say clean up /just/ kde-base/ > *, leaving the currently installed version and one previous version for > reference, cleaning out all others. (Sure I could put /everything/ else > on the exclude list, but what's really needed is an include list, plus a > "keep N more" option.) > > So I often end up cleaning packages like that out manually by simply > deleting them. My question is thus, does the remaining index/db/cache > entry get cleaned properly (when?) or am I leaving uncleanable garbage > behind when I do this? You can run 'emaint --fix binhost' to sync $PKGDIR/Packages up with the existing tbz2 files. If you don't run that emaint command, the packages that you removed will be pruned from $PKGDIR/Packages the next time that you run an 'emerge --usepkg' command with sufficient privileges. > Which of course translates into a couple of feature requests for the new > eclean-pkg: > > 1) Make it possible to clean only selected pkgs or categories. > > 2) Have an option to clean up and/or regenerate the cache/index/db/ > whatever files, re-syncing them with what's actually there. eclean-pkg calls 'emaint --fix binhost' to fix $PKGDIR/Packages after it removes some tbz2 files. > Meanwhile, another possible usage for multiple binpkgs per ebuild: > > I commonly run live-builds (mostly kde, tho I'm not ATM), and would > /love/ to be able to keep about three generations (current plus two back) > around, ideally IDed by their git-commit or the like. Running live > packages can mean even more risk than usual of something not working out, > but currently, if the package builds, by the time you find that out, > you've obliterated your previous *9999 binpkg and even figuring out which > git commit it was isn't easy, let alone doing a quick binpkg rollback, FWIW, you can use 'cp -rl $PKGDIR $PKGDIR.backup' to make a hardlink snapshot of $PKGDIR. Portage will break hardlinks whenever it needs to update tbz2 files, so you don't have to worry about updates in $PKGDIR affecting the files in $PKGDIR.backup. > like you'd do with an ordinary version upgrade. Were multiple live- > binpkg-versions kept around, IDed by the git-commit or at least with that > info in the metadata somewhere, it'd make things /so/ much easier! =:^) That's going to require an EAPI extension [1], in order to establish a protocol for the ebuild to communicate the commit id to the package manager. > But of course that does make having an automated cleaner that can keep > just the last N package versions around while deleting the others, that > much more important. Yes, and we might integrate some on-the-fly garbage collection directly into portage, or provide a hook for this purpose. [1] https://bugs.gentoo.org/show_bug.cgi?id=182028 -- Thanks, Zac