Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Matt Turner]

On Sat, Apr 7, 2018 at 12:57 PM, Lars Wendler  wrote:
> On Sat, 7 Apr 2018 14:16:33 -0500 William Hubbs wrote:
>
>>On Sat, Apr 07, 2018 at 02:55:53PM -0400, Michael Orlitzky wrote:
>>> On 04/07/2018 02:44 PM, William Hubbs wrote:
>>> >
>>> > I'm with floppym on this one. Is there a specific reason we enable
>>> > them globally?
>>>
>>> It's a relic from before we had IUSE defaults.
>>>
>>>
>>> > Since there has been so little discussion on this thread, I will
>>> > start looking at what I need to do to remove these use flags from
>>> > the profiles.
>>>
>>> There's probably a few packages that will need IUSE defaults to avoid
>>> breakage, and everyone else should get fair warning before the flags
>>> are turned off by default.
>>
>>There is the case of packages that optionally use a db back end,
>>and I would argue that those may not need iuse defaults.
>>
>>It could also be argued that having one backend enabled globally is
>>good for consistency, but that would end up leading down a bikeshed
>>path that I'm not sure we should go down. I'm just not sure it makes
>>sense to enable more than one of these backends globally.
>>
>>Thoughts?
>>
>>William
>>
>
> Considering the questionable license situation with latest sys-libs/db
> releases (AGPL), I'd say we should prefer gdbm over berkdb in case we
> want to keep one db backend default enabled.
> IIRC Fedora is even trying to entirely getting rid of berkdb.

Interesting. I wasn't aware of that. Here's a link with more information:

https://bugzilla.redhat.com/show_bug.cgi?id=1361971

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Lars Wendler]

On Sat, 7 Apr 2018 14:16:33 -0500 William Hubbs wrote:

>On Sat, Apr 07, 2018 at 02:55:53PM -0400, Michael Orlitzky wrote:
>> On 04/07/2018 02:44 PM, William Hubbs wrote:  
>> > 
>> > I'm with floppym on this one. Is there a specific reason we enable
>> > them globally?  
>> 
>> It's a relic from before we had IUSE defaults.
>> 
>>   
>> > Since there has been so little discussion on this thread, I will
>> > start looking at what I need to do to remove these use flags from
>> > the profiles.  
>> 
>> There's probably a few packages that will need IUSE defaults to avoid
>> breakage, and everyone else should get fair warning before the flags
>> are turned off by default.  
>
>There is the case of packages that optionally use a db back end,
>and I would argue that those may not need iuse defaults.
>
>It could also be argued that having one backend enabled globally is
>good for consistency, but that would end up leading down a bikeshed
>path that I'm not sure we should go down. I'm just not sure it makes
>sense to enable more than one of these backends globally.
>
>Thoughts?
>
>William
>

Considering the questionable license situation with latest sys-libs/db
releases (AGPL), I'd say we should prefer gdbm over berkdb in case we
want to keep one db backend default enabled.
IIRC Fedora is even trying to entirely getting rid of berkdb.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpZtUTHcE5fW.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[William Hubbs]

On Sat, Apr 07, 2018 at 02:55:53PM -0400, Michael Orlitzky wrote:
> On 04/07/2018 02:44 PM, William Hubbs wrote:
> > 
> > I'm with floppym on this one. Is there a specific reason we enable them
> > globally?
> 
> It's a relic from before we had IUSE defaults.
> 
> 
> > Since there has been so little discussion on this thread, I will start
> > looking at what I need to do to remove these use flags from the
> > profiles.
> 
> There's probably a few packages that will need IUSE defaults to avoid
> breakage, and everyone else should get fair warning before the flags are
> turned off by default.

There is the case of packages that optionally use a db back end,
and I would argue that those may not need iuse defaults.

It could also be argued that having one backend enabled globally is good
for consistency, but that would end up leading down a bikeshed path that
I'm not sure we should go down. I'm just not sure it makes sense to
enable more than one of these backends globally.

Thoughts?

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Michael Orlitzky]

On 04/07/2018 02:44 PM, William Hubbs wrote:
> 
> I'm with floppym on this one. Is there a specific reason we enable them
> globally?

It's a relic from before we had IUSE defaults.


> Since there has been so little discussion on this thread, I will start
> looking at what I need to do to remove these use flags from the
> profiles.

There's probably a few packages that will need IUSE defaults to avoid
breakage, and everyone else should get fair warning before the flags are
turned off by default.

But this is a noble goal; thanks.

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[William Hubbs]

On Thu, Jan 26, 2017 at 10:33:14PM -0500, Mike Gilbert wrote:
> I recently ran into a REQUIRED_USE constraint that required I select
> between berkdb and gdbm for an email client.
 
This has now hit stable and is affecting me because I can't upgrade the
email client without putting something in package.use.

> Looking through our profiles, I see we have both berkdb and gdbm
> enabled "globally".
> 
> default/linux/make.defaults:USE="berkdb crypt ipv6 ncurses nls pam
> readline ssl tcpd zlib"
> releases/make.defaults:USE="acl gdbm nptl unicode"
> 
> Is there any reason to have these USE flags enabled globally?
> 
> These USE seem pretty package-specific in scope. On my system, they
> are used by around a dozen of 1000+ installed packages. I think it
> might make sense to migrate them to appropriate IUSE defaults, or
> leave them disabled where they do not provide critical functionality.

I'm with floppym on this one. Is there a specific reason we enable them
globally?

Since there has been so little discussion on this thread, I will start
looking at what I need to do to remove these use flags from the
profiles.

Thanks,

William


signature.asc
Description: Digital signature

[gentoo-dev] Packages up for grabs: media-gfx/splashutils

[Jonas Stein]

Dear all,

The following packages are up for grabs:

media-gfx/splashutils

after retirement of the proxied maintainer due to inactivity.

https://packages.gentoo.org/packages/media-gfx/splashutils
There are 16 open bugs and patches.

https://bugs.gentoo.org/buglist.cgi?quicksearch=media-gfx%2Fsplashutils

Can anybody still install this package? It looks very broken to me after
reading the reports.

-- 
Best,
Jonas



















































signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH] _pkg_str: add _db attribute (bug 640318)

[Zac Medico]

In order to propagate information from dbapi to Package instance,
it's useful for each _pkg_str instance to have a _db attribute
which references the dbapi instance that instantiated it. Use a new
dbapi._iuse_implicit_cnstr method to delegate implicit IUSE logic to
the dbapi instance, in order to make the behavior customizable at the
dbapi level for the purposes of bug 640318. This patch consists only
of refactoring, with no behavioral changes.

Bug: https://bugs.gentoo.org/640318
---
 pym/_emerge/Package.py | 53 +-
 pym/_emerge/depgraph.py|  8 -
 pym/_emerge/resolver/DbapiProvidesIndex.py |  3 +-
 pym/portage/dbapi/__init__.py  | 44 +
 pym/portage/dbapi/bintree.py   | 15 +
 pym/portage/dbapi/porttree.py  |  4 +--
 pym/portage/dbapi/vartree.py   |  5 +--
 pym/portage/dbapi/virtual.py   |  4 +--
 pym/portage/versions.py|  6 ++--
 9 files changed, 81 insertions(+), 61 deletions(-)

diff --git a/pym/_emerge/Package.py b/pym/_emerge/Package.py
index 791a35612..a7ce00bc9 100644
--- a/pym/_emerge/Package.py
+++ b/pym/_emerge/Package.py
@@ -67,8 +67,19 @@ class Package(Task):
if not self.built:
self._metadata['CHOST'] = 
self.root_config.settings.get('CHOST', '')
eapi_attrs = _get_eapi_attrs(self.eapi)
+
+   try:
+   db = self.cpv._db
+   except AttributeError:
+   if self.built:
+   # For independence from the source ebuild 
repository and
+   # profile implicit IUSE state, require the _db 
attribute
+   # for built packages.
+   raise
+   db = self.root_config.trees['porttree'].dbapi
+
self.cpv = _pkg_str(self.cpv, metadata=self._metadata,
-   settings=self.root_config.settings)
+   settings=self.root_config.settings, db=db)
if hasattr(self.cpv, 'slot_invalid'):
self._invalid_metadata('SLOT.invalid',
"SLOT: invalid value: '%s'" % 
self._metadata["SLOT"])
@@ -82,17 +93,10 @@ class Package(Task):
# sync metadata with validated repo (may be UNKNOWN_REPO)
self._metadata['repository'] = self.cpv.repo
 
-   if eapi_attrs.iuse_effective:
-   implicit_match = 
self.root_config.settings._iuse_effective_match
-   if self.built:
-   implicit_match = functools.partial(
-   self._built_iuse_effective_match,
-   implicit_match, 
frozenset(self._metadata['USE'].split()))
-   else:
-   implicit_match = 
self.root_config.settings._iuse_implicit_match
+   implicit_match = db._iuse_implicit_cnstr(self.cpv, 
self._metadata)
usealiases = 
self.root_config.settings._use_manager.getUseAliases(self)
-   self.iuse = self._iuse(self, self._metadata["IUSE"].split(), 
implicit_match,
-   usealiases, self.eapi)
+   self.iuse = self._iuse(self, self._metadata["IUSE"].split(),
+   implicit_match, usealiases, self.eapi)
 
if (self.iuse.enabled or self.iuse.disabled) and \
not eapi_attrs.iuse_defaults:
@@ -115,33 +119,6 @@ class Package(Task):
type_name=self.type_name)
self._hash_value = hash(self._hash_key)
 
-   @staticmethod
-   def _built_iuse_effective_match(prof_effective_match, built_use, flag):
-   """
-   For built packages, it is desirable for the built USE setting 
to be
-   independent of the profile's current IUSE_IMPLICIT state, since 
the
-   profile's IUSE_IMPLICT setting may have diverged. Therefore, any
-   member of the built USE setting is considered to be a valid 
member of
-   IUSE_EFFECTIVE. Note that the binary package may be remote, so 
it's
-   only possible to rely on metadata that is available in the 
remote
-   Packages file, and the IUSE_IMPLICIT header in the Packages 
file is
-   vulnerable to mutation (see bug 640318).
-
-   This function is only used for EAPIs that support 
IUSE_EFFECTIVE,
-   since built USE settings for earlier EAPIs may contain a large
-   number of irrelevant flags.
-
-   @param prof_effective_match: function to match IUSE_EFFECTIVE
-   values for the current profile
-   @type prof_effective_match: callable
-   @param built_use: built USE setting
-