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 942021389E2 for ; Thu, 25 Dec 2014 10:03:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5A264E0A7F; Thu, 25 Dec 2014 10:03:36 +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 AFA8EE0A5B for ; Thu, 25 Dec 2014 10:03:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 0E09E34050D for ; Thu, 25 Dec 2014 10:03:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5.5 tests=[AWL=-0.784, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwdWBY3JuqDD for ; Thu, 25 Dec 2014 10:03:28 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 60BBF3405A3 for ; Thu, 25 Dec 2014 10:03:25 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Y45GJ-0003Mt-BG for gentoo-portage-dev@gentoo.org; Thu, 25 Dec 2014 11:03:19 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Dec 2014 11:03:19 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Dec 2014 11:03:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-portage-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-portage-dev] Re: [RFC] New file layout for PKGDIR and binhosts Date: Thu, 25 Dec 2014 10:03:05 +0000 (UTC) Message-ID: References: <549A1C31.8040500@gentoo.org> <549A4C25.9050000@gentoo.org> <549A75C5.70600@gentoo.org> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 4c6f250) X-Archives-Salt: ddfa9648-c438-40a0-874c-312efd5adc6f X-Archives-Hash: c0aa660ace60a9300b7bd75436136074 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? 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. 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, 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! =:^) 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. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman