[gentoo-portage-dev] [PATCH 2/3] portage/sync/syncbase.py: Change has_bin to an @property function
This avoids that self.logger is None error in the __init__(). --- pym/portage/sync/syncbase.py | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/pym/portage/sync/syncbase.py b/pym/portage/sync/syncbase.py index c820bcf..973d545 100644 --- a/pym/portage/sync/syncbase.py +++ b/pym/portage/sync/syncbase.py @@ -35,17 +35,23 @@ class SyncBase(object): self.xterm_titles = None self.spawn_kwargs = None self.bin_command = None - self.has_bin = False + self._bin_command = bin_command + self.bin_pkg = bin_pkg if bin_command: self.bin_command = portage.process.find_binary(bin_command) - if self.bin_command is None: - msg = [Command not found: %s % bin_command, - Type \emerge %s\ to enable %s support. % (bin_pkg, bin_command)] - for l in msg: - writemsg_level(!!! %s\n % l, - level=self.logger.ERROR, noiselevel=-1) - else: - self.has_bin = True + + + @property + def has_bin(self): + if self.bin_command is None: + msg = [Command not found: %s % self._bin_command, + Type \emerge %s\ to enable %s support. + % (self.bin_pkg, self._bin_command)] + for l in msg: + writemsg_level(!!! %s\n % l, + level=self.logger.ERROR, noiselevel=-1) + return False + return True def _kwargs(self, kwargs): -- 2.2.2
[gentoo-portage-dev] portage sync changes, fixes
From mgorny's recent suggestions and bug report... Plus a final pyflakes cleanup.
[gentoo-portage-dev] [PATCH 1/3] portage/sync: Break out a NewBase class from SyncBase
From mgorny's suggestion, rename _sync() to update().
Raise NotImplementedError in base classes.
Directly override sync() in websync module.
Fix up line spacing to be consistent.
---
pym/portage/sync/modules/cvs/cvs.py | 10 +++---
pym/portage/sync/modules/git/git.py | 8 ++---
pym/portage/sync/modules/rsync/rsync.py | 12 +++
pym/portage/sync/modules/svn/svn.py | 10 +++---
pym/portage/sync/modules/websync/websync.py | 21 +--
pym/portage/sync/syncbase.py| 56 ++---
6 files changed, 64 insertions(+), 53 deletions(-)
diff --git a/pym/portage/sync/modules/cvs/cvs.py
b/pym/portage/sync/modules/cvs/cvs.py
index 919cb34..9153815 100644
--- a/pym/portage/sync/modules/cvs/cvs.py
+++ b/pym/portage/sync/modules/cvs/cvs.py
@@ -7,10 +7,10 @@ import errno
import portage
from portage import os
from portage.util import writemsg_level
-from portage.sync.syncbase import SyncBase
+from portage.sync.syncbase import NewBase
-class CVSSync(SyncBase):
+class CVSSync(NewBase):
'''CVS sync module'''
short_desc = Perform sync operations on CVS repositories
@@ -21,7 +21,7 @@ class CVSSync(SyncBase):
def __init__(self):
- SyncBase.__init__(self, cvs, portage.const.CVS_PACKAGE_ATOM)
+ NewBase.__init__(self, cvs, portage.const.CVS_PACKAGE_ATOM)
def exists(self, **kwargs):
@@ -47,9 +47,9 @@ class CVSSync(SyncBase):
return (0, False)
- def _sync(self):
+ def update(self):
- Internal function to sync an existing CVS repository
+ Internal function to update an existing CVS repository
@return: tuple of return code (0=success), whether the cache
needs to be updated
diff --git a/pym/portage/sync/modules/git/git.py
b/pym/portage/sync/modules/git/git.py
index 3acfc2a..cea681c 100644
--- a/pym/portage/sync/modules/git/git.py
+++ b/pym/portage/sync/modules/git/git.py
@@ -10,10 +10,10 @@ from portage.output import create_color_func
good = create_color_func(GOOD)
bad = create_color_func(BAD)
warn = create_color_func(WARN)
-from portage.sync.syncbase import SyncBase
+from portage.sync.syncbase import NewBase
-class GitSync(SyncBase):
+class GitSync(NewBase):
'''Git sync class'''
short_desc = Perform sync operations on git based repositories
@@ -24,7 +24,7 @@ class GitSync(SyncBase):
def __init__(self):
- SyncBase.__init__(self, git, portage.const.GIT_PACKAGE_ATOM)
+ NewBase.__init__(self, git, portage.const.GIT_PACKAGE_ATOM)
def exists(self, **kwargs):
@@ -67,7 +67,7 @@ class GitSync(SyncBase):
return (os.EX_OK, True)
- def _sync(self):
+ def update(self):
''' Update existing git repository, and ignore the syncuri. We
are
going to trust the user and assume that the user is in the
branch
that he/she wants updated. We'll let the user manage branches
with
diff --git a/pym/portage/sync/modules/rsync/rsync.py
b/pym/portage/sync/modules/rsync/rsync.py
index 52d8b0f..817164d 100644
--- a/pym/portage/sync/modules/rsync/rsync.py
+++ b/pym/portage/sync/modules/rsync/rsync.py
@@ -21,14 +21,14 @@ from portage.const import VCS_DIRS, TIMESTAMP_FORMAT,
RSYNC_PACKAGE_ATOM
from portage.util import writemsg, writemsg_stdout
from portage.sync.getaddrinfo_validate import getaddrinfo_validate
from _emerge.UserQuery import UserQuery
-from portage.sync.syncbase import SyncBase
+from portage.sync.syncbase import NewBase
SERVER_OUT_OF_DATE = -1
EXCEEDED_MAX_RETRIES = -2
-class RsyncSync(SyncBase):
+class RsyncSync(NewBase):
'''Rsync sync module'''
short_desc = Perform sync operations on rsync based repositories
@@ -39,11 +39,11 @@ class RsyncSync(SyncBase):
def __init__(self):
- SyncBase.__init__(self, rsync, RSYNC_PACKAGE_ATOM)
+ NewBase.__init__(self, rsync, RSYNC_PACKAGE_ATOM)
- def _sync(self):
- '''Internal sync function which performs only the sync'''
+ def update(self):
+ '''Internal update function which performs the transfer'''
opts = self.options.get('emerge_config').opts
self.usersync_uid = self.options.get('usersync_uid', None)
enter_invalid = '--ask-enter-invalid' in opts
@@ -287,7 +287,7 @@ class RsyncSync(SyncBase):
'Created New Directory %s ' %
self.repo.location )
except IOError:
return (1, False)
- return self._sync()
+ return self.update()
def _set_rsync_defaults(self):
diff --git a/pym/portage/sync/modules/svn/svn.py
b/pym/portage/sync/modules/svn/svn.py
index 60ead4b..492ada3 100644
--- a/pym/portage/sync/modules/svn/svn.py
+++
[gentoo-portage-dev] [PATCH 3/3] portage/sync: Some final pyflakes code cleanup
---
pym/portage/sync/modules/cvs/cvs.py | 1 -
pym/portage/sync/modules/git/git.py | 6 --
pym/portage/sync/modules/svn/svn.py | 5 ++---
pym/portage/sync/modules/websync/websync.py | 4
4 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/pym/portage/sync/modules/cvs/cvs.py
b/pym/portage/sync/modules/cvs/cvs.py
index 9153815..9b382ab 100644
--- a/pym/portage/sync/modules/cvs/cvs.py
+++ b/pym/portage/sync/modules/cvs/cvs.py
@@ -2,7 +2,6 @@
# Distributed under the terms of the GNU General Public License v2
import logging
-import errno
import portage
from portage import os
diff --git a/pym/portage/sync/modules/git/git.py
b/pym/portage/sync/modules/git/git.py
index cea681c..7a710ef 100644
--- a/pym/portage/sync/modules/git/git.py
+++ b/pym/portage/sync/modules/git/git.py
@@ -36,8 +36,6 @@ class GitSync(NewBase):
'''Do the initial clone of the repository'''
if kwargs:
self._kwargs(kwargs)
- emerge_config = self.options.get('emerge_config', None)
- portdb = self.options.get('portdb', None)
try:
if not os.path.exists(self.repo.location):
os.makedirs(self.repo.location)
@@ -73,10 +71,6 @@ class GitSync(NewBase):
that he/she wants updated. We'll let the user manage branches
with
git directly.
'''
- # No kwargs call here; this is internal, so it should have been
- # called by something which set the internal variables
- emerge_config = self.options.get('emerge_config', None)
- portdb = self.options.get('portdb', None)
git_cmd = %s pull % self.bin_command
writemsg_level(git_cmd + \n)
diff --git a/pym/portage/sync/modules/svn/svn.py
b/pym/portage/sync/modules/svn/svn.py
index 492ada3..da38e6f 100644
--- a/pym/portage/sync/modules/svn/svn.py
+++ b/pym/portage/sync/modules/svn/svn.py
@@ -2,7 +2,6 @@
# Distributed under the terms of the GNU General Public License v2
import logging
-import errno
import portage
from portage import os
@@ -55,7 +54,7 @@ class SVNSync(NewBase):
@rtype: (int, bool)
- exitcode, d = self._svn_upgrade()
+ exitcode = self._svn_upgrade()
if exitcode != os.EX_OK:
return (exitcode, False)
@@ -87,4 +86,4 @@ class SVNSync(NewBase):
msg = !!! svn upgrade error; exiting.
self.logger(self.xterm_titles, msg)
writemsg_level(msg + \n, noiselevel=-1,
level=logging.ERROR)
- return (exitcode, False)
+ return exitcode
diff --git a/pym/portage/sync/modules/websync/websync.py
b/pym/portage/sync/modules/websync/websync.py
index 3576116..b22a2a4 100644
--- a/pym/portage/sync/modules/websync/websync.py
+++ b/pym/portage/sync/modules/websync/websync.py
@@ -35,9 +35,6 @@ class WebRsync(SyncBase):
if not self.has_bin:
return (1, False)
- emerge_config = self.options.get('emerge_config', None)
- portdb = self.options.get('portdb', None)
-
exitcode = portage.process.spawn_bash(%s % \
(self.bin_command),
**portage._native_kwargs(self.spawn_kwargs))
@@ -46,7 +43,6 @@ class WebRsync(SyncBase):
self.logger(self.xterm_titles, msg)
writemsg_level(msg + \n, level=logging.ERROR,
noiselevel=-1)
return (exitcode, False)
- #return self.post_sync(portdb, self.repo.location,
emerge_config)
return (exitcode, True)
--
2.2.2
Re: [gentoo-portage-dev] [PATCH] Generate soname dependency metadata (282639)
On 01/26/15 22:16, Zac Medico wrote: Generate soname dependency metadata for binary and installed packages, in the form of PROVIDES and REQUIRES metadata. It is useful to generate PROVIDES and REQUIRES metadata now, so that it will be available when dependency resolver support is added in the future. Note that slot-operator dependencies will not be able to serve as a substitute for soname dependencies for the forseeable future, because system dependencies are frequently unspecified (according to Gentoo policy). Thanks for putting this into the commit message. Getting the point across to people was at times painful. The PROVIDES/REQUIRES system is very similar to the automatic Requires and Provides system which is supported by RPM. The PROVIDES/REQUIRES metadata is generated automatically from the ELF files that are installed by a package. The PROVIDES/REQUIRES syntax is described in the /var/db/pkg section of the portage(5) man page. REQUIRES_EXCLUDE and PROVIDES_EXCLUDE ebuild variables allow for filtering of the sonames that are saved in REQUIRES and PROVIDES (see the ebuild(5) man page for details). ELF gets us like 99% of the way but will eventually have to think about Mach-O for gentoo-on-mac etc. Maybe COFF, a.out. Not sure where to draw the line. The /var/db/pkg NEEDED.ELF.2 format now includes an additional field which indicates the multilib category, as discussed in bug #534206. The multilib category is used to categorize the sonames that are listed in PROVIDES/REQUIRES metadata, since sonames need to be resolved separately for each multilib category. The complete list of supported multilib categories is documented in the comments of the portage.dep.soname.multilib_category module. X-Gentoo-Bug: 282639 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=282639 --- bin/ebuild.sh | 2 +- bin/phase-functions.sh | 2 +- man/ebuild.5| 12 +++ man/portage.5 | 25 + pym/_emerge/Package.py | 3 +- pym/portage/dbapi/bintree.py| 5 +- pym/portage/dbapi/vartree.py| 1 + pym/portage/dep/soname/__init__.py | 2 + pym/portage/dep/soname/multilib_category.py | 112 +++ pym/portage/package/ebuild/doebuild.py | 86 -- pym/portage/util/_dyn_libs/LinkageMapELF.py | 61 ++--- pym/portage/util/_dyn_libs/NeededEntry.py | 83 + pym/portage/util/_dyn_libs/soname_deps.py | 136 pym/portage/util/elf/__init__.py| 2 + pym/portage/util/elf/constants.py | 36 pym/portage/util/elf/header.py | 62 + pym/portage/util/endian/__init__.py | 2 + pym/portage/util/endian/decode.py | 56 18 files changed, 661 insertions(+), 27 deletions(-) create mode 100644 pym/portage/dep/soname/__init__.py create mode 100644 pym/portage/dep/soname/multilib_category.py create mode 100644 pym/portage/util/_dyn_libs/NeededEntry.py create mode 100644 pym/portage/util/_dyn_libs/soname_deps.py create mode 100644 pym/portage/util/elf/__init__.py create mode 100644 pym/portage/util/elf/constants.py create mode 100644 pym/portage/util/elf/header.py create mode 100644 pym/portage/util/endian/__init__.py create mode 100644 pym/portage/util/endian/decode.py I can't speak to the integration into portage. I'm sure you got that right. I'll comment on the elf-ish stuff. diff --git a/man/portage.5 b/man/portage.5 index 189561c..bf159fd 100644 --- a/man/portage.5 +++ b/man/portage.5 @@ -1443,6 +1443,31 @@ can be changed quickly. Generally though there is one file per environment variable that matters (like CFLAGS) with the contents stored inside of it. Another common file is the CONTENTS file which lists the path and hashes of all objects that the package installed onto your system. +.TP +.BR PROVIDES +Contains information about the sonames that a package provides, which is +automatically generated from the files that it installs. The sonames +may have been filtered by the \fBPROVIDES_EXCLUDE\fR \fBebuild\fR(5) +variable. A multilib category, followed by a colon, always preceeds a +list of one or more sonames. + +.I Example: +.nf +x86_32: libcom_err.so.2 libss.so.2 x86_64: libcom_err.so.2 libss.so.2 +.fi +.TP +.BR REQUIRES +Contains information about the sonames that a package requires, which is +automatically generated from the files that it installs. The sonames +may have been filtered by the \fBREQUIRES_EXCLUDE\fR \fBebuild\fR(5) +variable. Any sonames that a package provides are automatically excluded +from \fBREQUIRES\fR. A multilib category, followed by a colon, always +preceeds a list of one or more sonames. + +.I Example: +.nf +x86_32: ld-linux.so.2 libc.so.6 x86_64: ld-linux-x86-64.so.2
Re: [gentoo-portage-dev] [PATCH] Generate soname dependency metadata (282639)
On 01/29/2015 04:54 PM, Anthony G. Basile wrote:
On 01/26/15 22:16, Zac Medico wrote:
ELF gets us like 99% of the way but will eventually have to think about
Mach-O for gentoo-on-mac etc. Maybe COFF, a.out. Not sure where to
draw the line.
Yeah, I guess we can let the Prefix team decide on that stuff.
I'm a bit confused here. So PROVIDES and REQUIRES are new files in
/var/db/pkg/cat/pkg?
Right.
And the format of NEEDED.ELF.2 is not changing? Correct?
It has one new field, for the multilib category (same as the abstract
abi identifier discussed in bug 534206). I didn't bother to document it,
since is was already completely undocumented. I suppose it would be nice
to have it documented in portage.5, though.
We should note at some point that arm_32 means EABI and not OABI which
are two different 32-bit arm abis. We don't support oabi in gentoo
anymore, but still this can be confusing. If it did come up in some
context, we could distinguish it as arm_o32 like mips below.
Yeah, I'm inclined to just wait for someone to request support for
something like this, and deal with it then.
We probably don't have to note that arm_64 is aarch6 which is really a
different ISA, not backwards compatible to 32-bit arm. As you say below
this is just a naming convention, but in every other case each line does
refer to one ISA, except maybe ia_32 can be confused with x86.
Well, wikipedia says AArch64 provides user-space compatibility with
ARMv7-A ISA [1], so I think that's a good enough reason to stick with
arm_{32,64} for now.
+#hppa_{32,64}
+#ia_{32,64}
+#m68k_{32,64}
+#mips_{eabi32,eabi64,n32,n64,o32,o64}
+#ppc_{32,64}
+#s390_{32,64}
+#sh_{32,64}
+#sparc_{32,64}
+#x86_{32,64,x32}
+#
+# NOTES:
+#
+# * The ABIs referenced by some of the above *_32 and *_64 categories
+# may be imaginary, but they are listed anyway, since the goal is to
+# establish a naming convention that is as consistent and uniform as
+# possible.
+#
+# * The Elf header's e_ident[EI_OSABI] byte is completely ignored,
+# since OS-independence is one of the goals. The assumption is that,
+# for given installation, we are only interested in tracking multilib
+# ABIs for a single OS.
If you run readelf -h on (say) bash in any of our stage3's tarballs you
always get OS/ABI: UNIX - System V irrespective of arch and abi. I
don't know what you would get on BSD, but the field is totally
irrelevant for our purposes despite the name. As far as I can tell, it
is totally invariant across arches and abis.
You can even unpack the the stage3's on an amd64 host and run readelf
form the host on the chroot target and you'll get the elf header, so you
don't need access to native hardware.
The comment suggests that there might be some interesting information
there, but there isn't. Maybe I'm just reading too much into it.
Well, a quick google search seems to indicate that FreeBSD uses
EI_OSABI. I was specifically thinking about FreeBSD when I wrote that
comment, because I was aware that Gentoo/FBSD was using ELF, and I just
assumed that they would have a different EI_OSABI than Linux.
diff --git a/pym/portage/util/_dyn_libs/NeededEntry.py
b/pym/portage/util/_dyn_libs/NeededEntry.py
new file mode 100644
index 000..5de59a0
--- /dev/null
+++ b/pym/portage/util/_dyn_libs/NeededEntry.py
@@ -0,0 +1,83 @@
+# Copyright 2015 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+from __future__ import unicode_literals
+
+import sys
+
+from portage import _encodings, _unicode_encode
+from portage.exception import InvalidData
+from portage.localization import _
+
+class NeededEntry(object):
+
+Represents one entry (line) from a NEEDED.ELF.2 file. The entry
+must have 5 or more semicolon-delimited fields in order to be
+considered valid. The sixth field is optional, corresponding
+to the multilib category. The multilib_category attribute is
+None if the corresponding field is either empty or missing.
+
+
+__slots__ = (arch, filename, multilib_category, needed,
+runpaths, soname)
Looks like this answers my question above about the format of NEEDED.ELF.2
Yeah, maybe this is enough documentation for those who would be interested.
Nice logic here :) The only thing that I don't get is why we might need
{provides,requires}_exclude patterns. I guess its good design
principles but I can't think of a use case.
I copied the idea from Fedora [2]. Since the soname dependencies are
automatically generated, we want to be able to filter them if necessary,
though hopefully it won't be needed very often.
b/pym/portage/util/elf/constants.py
new file mode 100644
index 000..3857b71
--- /dev/null
+++ b/pym/portage/util/elf/constants.py
Document where these are coming from else we'll loose the connection to
the standard. They should all be in elf.h provided by
Re: [gentoo-portage-dev] [PATCH] Generate soname dependency metadata (282639)
Dnia 2015-01-26, o godz. 19:16:28
Zac Medico zmed...@gentoo.org napisał(a):
Generate soname dependency metadata for binary and installed packages,
in the form of PROVIDES and REQUIRES metadata. It is useful to generate
PROVIDES and REQUIRES metadata now, so that it will be available
when dependency resolver support is added in the future. Note that
slot-operator dependencies will not be able to serve as a substitute
for soname dependencies for the forseeable future, because system
dependencies are frequently unspecified (according to Gentoo policy).
The PROVIDES/REQUIRES system is very similar to the automatic Requires
and Provides system which is supported by RPM. The PROVIDES/REQUIRES
metadata is generated automatically from the ELF files that are
installed by a package. The PROVIDES/REQUIRES syntax is described in
the /var/db/pkg section of the portage(5) man page. REQUIRES_EXCLUDE
and PROVIDES_EXCLUDE ebuild variables allow for filtering of the
sonames that are saved in REQUIRES and PROVIDES (see the ebuild(5) man
page for details).
The /var/db/pkg NEEDED.ELF.2 format now includes an additional field
which indicates the multilib category, as discussed in bug #534206. The
multilib category is used to categorize the sonames that are listed in
PROVIDES/REQUIRES metadata, since sonames need to be resolved
separately for each multilib category. The complete list of supported
multilib categories is documented in the comments of the
portage.dep.soname.multilib_category module.
X-Gentoo-Bug: 282639
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=282639
---
bin/ebuild.sh | 2 +-
bin/phase-functions.sh | 2 +-
man/ebuild.5| 12 +++
man/portage.5 | 25 +
pym/_emerge/Package.py | 3 +-
pym/portage/dbapi/bintree.py| 5 +-
pym/portage/dbapi/vartree.py| 1 +
pym/portage/dep/soname/__init__.py | 2 +
pym/portage/dep/soname/multilib_category.py | 112 +++
pym/portage/package/ebuild/doebuild.py | 86 --
pym/portage/util/_dyn_libs/LinkageMapELF.py | 61 ++---
pym/portage/util/_dyn_libs/NeededEntry.py | 83 +
pym/portage/util/_dyn_libs/soname_deps.py | 136
pym/portage/util/elf/__init__.py| 2 +
pym/portage/util/elf/constants.py | 36
pym/portage/util/elf/header.py | 62 +
pym/portage/util/endian/__init__.py | 2 +
pym/portage/util/endian/decode.py | 56
18 files changed, 661 insertions(+), 27 deletions(-)
create mode 100644 pym/portage/dep/soname/__init__.py
create mode 100644 pym/portage/dep/soname/multilib_category.py
create mode 100644 pym/portage/util/_dyn_libs/NeededEntry.py
create mode 100644 pym/portage/util/_dyn_libs/soname_deps.py
create mode 100644 pym/portage/util/elf/__init__.py
create mode 100644 pym/portage/util/elf/constants.py
create mode 100644 pym/portage/util/elf/header.py
create mode 100644 pym/portage/util/endian/__init__.py
create mode 100644 pym/portage/util/endian/decode.py
diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index e6f9cb9..b6b3723 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -578,7 +578,7 @@ if ! has $EBUILD_PHASE clean cleanrm ; then
# interaction begins.
unset EAPI DEPEND RDEPEND PDEPEND HDEPEND INHERITED IUSE
REQUIRED_USE \
ECLASS E_IUSE E_REQUIRED_USE E_DEPEND E_RDEPEND
E_PDEPEND \
- E_HDEPEND
+ E_HDEPEND PROVIDES_EXCLUDE REQUIRES_EXCLUDE
if [[ $PORTAGE_DEBUG != 1 || ${-/x/} != $- ]] ; then
source $EBUILD || die error sourcing ebuild
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index aec86fd..def2080 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -580,7 +580,7 @@ __dyn_install() {
for f in ASFLAGS CBUILD CC CFLAGS CHOST CTARGET CXX \
CXXFLAGS EXTRA_ECONF EXTRA_EINSTALL EXTRA_MAKE \
LDFLAGS LIBCFLAGS LIBCXXFLAGS QA_CONFIGURE_OPTIONS \
- QA_DESKTOP_FILE ; do
+ QA_DESKTOP_FILE PROVIDES_EXCLUDE REQUIRES_EXCLUDE ; do
x=$(echo -n ${!f})
[[ -n $x ]] echo $x $f
done
diff --git a/man/ebuild.5 b/man/ebuild.5
index b587264..c2cbe4b 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -480,6 +480,12 @@ source source\-build which is scheduled for merge
.TE
.RE
.TP
+.B PROVIDES_EXCLUDE\fR = \fI[space delimited list of fnmatch patterns]\fR
+Sonames and file paths matched by these fnmatch patterns will be
+excluded during genertion of \fBPROVIDES\fR metadata (see
Re: [gentoo-portage-dev] [PATCH 2/3] portage/sync/syncbase.py: Change has_bin to an @property function
On 01/29/2015 11:45 AM, Brian Dolbec wrote: This avoids that self.logger is None error in the __init__(). --- pym/portage/sync/syncbase.py | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/pym/portage/sync/syncbase.py b/pym/portage/sync/syncbase.py index c820bcf..973d545 100644 --- a/pym/portage/sync/syncbase.py +++ b/pym/portage/sync/syncbase.py @@ -35,17 +35,23 @@ class SyncBase(object): self.xterm_titles = None self.spawn_kwargs = None self.bin_command = None - self.has_bin = False + self._bin_command = bin_command + self.bin_pkg = bin_pkg if bin_command: self.bin_command = portage.process.find_binary(bin_command) - if self.bin_command is None: - msg = [Command not found: %s % bin_command, - Type \emerge %s\ to enable %s support. % (bin_pkg, bin_command)] - for l in msg: - writemsg_level(!!! %s\n % l, - level=self.logger.ERROR, noiselevel=-1) - else: - self.has_bin = True + + + @property + def has_bin(self): + if self.bin_command is None: + msg = [Command not found: %s % self._bin_command, + Type \emerge %s\ to enable %s support. + % (self.bin_pkg, self._bin_command)] + for l in msg: + writemsg_level(!!! %s\n % l, + level=self.logger.ERROR, noiselevel=-1) + return False + return True def _kwargs(self, kwargs): Maybe it should be named _has_bin instead, since it should only be called by a subclass after it has called _kwargs to initialize self.logger. Otherwise, somebody might think they can access has_bin before _kwargs has been called. -- Thanks, Zac
Re: [gentoo-portage-dev] [PATCH 3/3] portage/sync: Some final pyflakes code cleanup
On 01/29/2015 11:45 AM, Brian Dolbec wrote: --- pym/portage/sync/modules/cvs/cvs.py | 1 - pym/portage/sync/modules/git/git.py | 6 -- pym/portage/sync/modules/svn/svn.py | 5 ++--- pym/portage/sync/modules/websync/websync.py | 4 4 files changed, 2 insertions(+), 14 deletions(-) LGTM. -- Thanks, Zac
Re: [gentoo-portage-dev] [PATCH 1/3] portage/sync: Break out a NewBase class from SyncBase
On 01/29/2015 11:45 AM, Brian Dolbec wrote: From mgorny's suggestion, rename _sync() to update(). Raise NotImplementedError in base classes. Directly override sync() in websync module. Fix up line spacing to be consistent. --- pym/portage/sync/modules/cvs/cvs.py | 10 +++--- pym/portage/sync/modules/git/git.py | 8 ++--- pym/portage/sync/modules/rsync/rsync.py | 12 +++ pym/portage/sync/modules/svn/svn.py | 10 +++--- pym/portage/sync/modules/websync/websync.py | 21 +-- pym/portage/sync/syncbase.py| 56 ++--- 6 files changed, 64 insertions(+), 53 deletions(-) Looks good, but it feels a little bit crazy to split out a NewBase class when WebRsync is the only one that doesn't inherit from it. WebRsync is a very special case, and it could just as well inherit from NewBase, with the new() method calling update(). -- Thanks, Zac
[gentoo-portage-dev] Re: [gentoo-dev] [PATCH] pym/portage/news.py: let slackers copy+paste the news read command
On Thu, 29 Jan 2015, Zac Medico wrote: -print(Use + colorize(GOOD, eselect news) + to read news items.) +print(Use + colorize(GOOD, eselect news read new) + to read new items.) I guess that's fine, but I have to wonder how many people are really that lazy. To me, it actually seems like more effort to highlight the span of characters with the mouse than it does to type them out. Also, when the work read appears twice on a short line like that, it gives a wordy/redundant feeling. Also new is the default for eselect's read action, therefore eselect news read would be enough. Ulrich pgpjeToyup0vH.pgp Description: PGP signature
