[gentoo-portage-dev] [PATCH] repoman: handle removed packages in vcs_files_to_cps (bug 546010)
Make vcs_files_to_cps exclude packages that have been removed, since calling code assumes that the packages exist. X-Gentoo-Bug: 546010 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=546010 --- bin/repoman | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/bin/repoman b/bin/repoman index 7101a00..7bcb89f 100755 --- a/bin/repoman +++ b/bin/repoman @@ -1047,7 +1047,10 @@ def vcs_files_to_cps(vcs_file_iter): if len(f_split) 3 and f_split[1] in categories: modified_cps.append(/.join(f_split[1:3])) - return frozenset(modified_cps) + # Exclude packages that have been removed, since calling + # code assumes that the packages exists. + return frozenset(x for x in frozenset(modified_cps) + if os.path.exists(os.path.join(repodir, x))) def git_supports_gpg_sign(): status, cmd_output = \ -- 2.3.1
[gentoo-portage-dev] Re: Dynamic USE dependencies
Rich Freeman ri...@gentoo.org wrote: Keep in mind that keeping track of past decisions made by portage does not require user-editable config files in /etc. Yes, but you might not always agree with portage's decisions, and the resolution might be non-unique. Although the user might always influence it with /etc/portage/package.use it might be better to keep this transparent to the user - therefore, I suggested a directory in /etc and not in /var (Moreover, a cache would not make sense, since the previous decision could always be trivially calculated from /var/db/pkg, and the user-selected state of the USE-flag for the corresponding package. You could not check the validity of such a cache, since you cannot check whether USE or /etc/portage/package.use has changed) That said, portage still has to spend time basically re-validating the consistency of the entire system *Validating* consistency is not time-consuming. Looking for possibilities to unset use-flags is a much more time-consuming story. If everything is consistent or can easily be resolved, you hardly need any backtracking...
Re: [gentoo-portage-dev] Re: [PATCH] Enable cgroup, ipc-sandbox network-sandbox by default
On 04/08/2015 07:03 AM, Martin Vaeth wrote: Michał Górny mgo...@gentoo.org wrote: All the features degrade gracefully when the relevant kernel features are not available. In conncetion with some old version of rescuecd, and fetching files, one can run into troubles with FEATURES=cgroups https://forums.gentoo.org/viewtopic-t-1009074-start-0-postdays-0-postorder-asc-highlight-.html (The bad thing was that this error happened, before it was clear that portage attempted to fetch files) IOError: [Errno 22] Invalid argument is thrown when writing to cgroup.procs in portage.process._exec(). We need to detect whatever conditions cause this inside AbstractEbuildProcess._start(), and disable the cgroup usage in that case. -- Thanks, Zac
[gentoo-portage-dev] Re: [PATCH] Enable cgroup, ipc-sandbox network-sandbox by default
Michał Górny mgo...@gentoo.org wrote: All the features degrade gracefully when the relevant kernel features are not available. In conncetion with some old version of rescuecd, and fetching files, one can run into troubles with FEATURES=cgroups https://forums.gentoo.org/viewtopic-t-1009074-start-0-postdays-0-postorder-asc-highlight-.html (The bad thing was that this error happened, before it was clear that portage attempted to fetch files)
[gentoo-portage-dev] Re: Dynamic USE dependencies
Rich Freeman ri...@gentoo.org wrote: 1. They can STILL populate /etc/portage/package.use 2. They could manually install a package with one-time specified USE Why do we need another mechanism to control what flags a package gets installed We do not *need* it. By why reject it if you can get it for free by just making the it transparent to the user? The user should be able to decide e.g. when to clean it up and select perhaps e.g. only a certain classes which should be cleaned up (e.g. by removing all/certain cpu_flags_x86 and letting them regenerate).
