On 07/24/19 10:40, Kent Fredric wrote: > On Tue, 23 Jul 2019 23:56:52 -0400 > desultory wrote: > >> avoid optional documentation, >> while the proposal in question explicitly would > > I assume you meant 'optional dependencies' here right? :) > The user-side effects pf the proposal in question, were it to become policy, would be that anyone seeking to not install what is presently optional documentation would either be: (1) wasting build time and space (and, depending on implementation, dependencies) on their build system (potentially masking the files from being installed); (2) wasting the space in their installed image(s) (if they did not mask the files which would not currently be installed anyway); or (3) wasting their own time working around what the developers would be required by policy to implement by repackaging the software themselves to avoid the time and space drawbacks (though this would generally be expected to be a rather exceptional case, as it would be relatively extreme to avoid what would be a distfile and some file masking from the user side). Developer-side effects of the proposal in question would explicitly force developers to use bespoke workarounds to avoid adding optional dependencies to packages, for questionable gains. So, while I was commenting on user-side effects, the phrasing applies to developer-side effects given s/documentation/dependencies/. As I have noted elsewhere, there is a solution for which the majority of the tooling exists which could achieve the same ends as the proposal in question without causing developers in general significant additional overhead beyond the status quo, while as a side effect providing additional services to users. However, the proposal in question specifically avoids offloading the newly generated work to automated systems in favor of, evidently, optimizing for maximum consumption of resources with minimal standardization.
On 7/24/19 1:16 AM, Michał Górny wrote: > Dnia July 24, 2019 6:19:05 AM UTC, Ulrich Mueller > napisał(a): >>> On Tue, 23 Jul 2019, Michał Górny wrote: >> >>> Make repoman report user.eclass as deprecated by GLEP 81. >> >> I don't understand. user.eclass is inherited by both acct-user.eclass >> and acct-group.eclass, therefore in active use. >> >> Or are you planning to inline its code in the inheriting eclasses? > > This doesn't trigger for indirect inherits. Unless I tested wrong. Correct. This checks direct inherits that are parsed from the ebuild file. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
# Andreas Sturmlechner (2019-07-24) # Unmaintained and broken with current Plasma, removal in 30 days # Bugs: https://bugs.kde.org/show_bug.cgi?id=404359, # https://bugs.kde.org/show_bug.cgi?id=404360, see also HOMEPAGE comments kde-misc/plasma-active-window-control
Hi Gentoo Developers, I'm finalizing the GSoC2019 project "BLAS and LAPACK runtime switch". The documentation for user and developer is available here: https://wiki.gentoo.org/wiki/Blas-lapack-switch BLAS and LAPACK are dense numerical algebra libraries of "libc-importance" to scientific computing users. The runtime switching mechanism enables users to easily switch the BLAS/LAPACK library system-wide, without recompiling anything. A similar feature has been long-existing in Debian system, as known as the update-alternatives mechanism. In Gentoo we implemented this feature with eselect modules. This mechanism has been tested by some users and gentoo science team developers. Thanks to these early testers, we've got some positive feed backs: https://github.com/gentoo/sci/issues/805#issuecomment-510469206 https://github.com/gentoo/sci/issues/805#issuecomment-512097570 I sincerely invite users and developers who heavily rely on BLAS/LAPACK libraries to test it. Should you find any problem, or have any suggestion/question, please let me know :-)  https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2019/Ideas/BLAS_and_LAPACK_runtime_switching
On Tue, 23 Jul 2019 23:56:52 -0400 desultory wrote: > avoid optional documentation, > while the proposal in question explicitly would I assume you meant 'optional dependencies' here right? :) pgp36j4n0ZoM_.pgp Description: OpenPGP digital signature
Dnia July 24, 2019 6:19:05 AM UTC, Ulrich Mueller napisał(a): >> On Tue, 23 Jul 2019, Michał Górny wrote: > >> Make repoman report user.eclass as deprecated by GLEP 81. > >I don't understand. user.eclass is inherited by both acct-user.eclass >and acct-group.eclass, therefore in active use. > >Or are you planning to inline its code in the inheriting eclasses? This doesn't trigger for indirect inherits. Unless I tested wrong. > >Ulrich -- Best regards, Michał Górny
> On Tue, 23 Jul 2019, Michał Górny wrote: > Make repoman report user.eclass as deprecated by GLEP 81. I don't understand. user.eclass is inherited by both acct-user.eclass and acct-group.eclass, therefore in active use. Or are you planning to inline its code in the inheriting eclasses? Ulrich signature.asc Description: PGP signature