Summary: | portage-2.1_rc3 fetch error | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Constantine Kardaris <ckardaris> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | selinux |
Priority: | High | Keywords: | InVCS, REGRESSION |
Version: | 2.1 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 115839 | ||
Attachments: | use trusty selinux_aux functions |
Description
Constantine Kardaris
2006-05-29 03:18:30 UTC
Created attachment 87790 [details, diff]
use trusty selinux_aux functions
Can you please test this patch? If you save it as /tmp/selinux.patch, you can apply it as follows:
cd /usr/lib/portage
patch -p0 < /tmp/selinux.patch
it works ok for me (In reply to comment #2) > it works ok for me Thanks for testing. The patch is in svn r3438. Since this only affects selinux users, I've added the patch to portage-2.1_rc3-r1 (no need to revbump). (In reply to comment #3) > (In reply to comment #2) > > it works ok for me > > Thanks for testing. The patch is in svn r3438. Since this only affects > selinux users, I've added the patch to portage-2.1_rc3-r1 (no need to revbump). > I don't see how it affecting selinux only != a revbump. If the ebuild changes what gets installed, you revbump, regardless of the affected class of users. (In reply to comment #4) > If the ebuild changes what gets installed, you revbump, regardless of the > affected class of users. Not completely true, it's a cost/benefit question. In this case I'd probably agree with you though as portage updates don't cost much, but OTOH it's a tiny usergroup and looking at the past few weeks we'll get a revbump soon anyway. Okay, so I twisted this part a little and used it for a runtime error instead of a compile time error: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1 Likewise, if you fix a compilation problem in the ebuild that was affecting some users, there is no need to bump the revision number, since those for whom it worked perfectly would see no benefit in installing a new revision, and those who experienced the problem do not have the package installed (since compilation failed) and thus have no need for the new revision number to force an upgrade. I'll go ahead with the revbump... This has been released in 2.1_rc3-r2. |