On Sun, 9 Jul 2017 21:37:11 -0400
"Walter Dnes" wrote:
>
> "Fat-Finger" does happen once in while. Removing the risk of it
> happening in the first place is a lot more robust/bulletproof.
There is nothing in place to stop you from removing gcc, or other
system packages. Adding such to a set, r
On 07/09/2017 06:53 AM, William L. Thomson Jr. wrote:
> On Sun, 9 Jul 2017 00:42:46 -0700
> Daniel Campbell wrote:
>
>>> - Sets used in profiles cannot have use expansion, versions or
>>> anything beyond cat/pkg.
>> This would break some set behavior, at least in Portage. Specifying a
>> singl
On Sun, Jul 09, 2017 at 09:49:08AM -0400, William L. Thomson Jr. wrote
> On Sun, 9 Jul 2017 05:24:19 -0400
> "Walter Dnes" wrote:
>
> > Yes, for gcc.
>
> Which if someone ignores warnings, and breaks their system, it is on
> them. At that point your best to remove said package from the set, an
polynomial-c
b980daeece8
dev-libs/volume_key 20170706-08:27 polynomial-c
a1f1e3e691b
dev-ml/ocsigen-i18n 20170709-15:11 aballier
29d65473417
dev-php/pecl-dbase20170707-15:25 grknight
b276310aa80
dev-php/pecl-zmq
It's the only entry of all profiles without '*'.
portage/gentoo/profiles $ grep '^[^*-\#]' $(find -name packages)
./uclibc/packages:app-misc/pax-utils
It's an ancient entry from 2005:
https://github.com/gentoo/gentoo-gitmig-20150809-draft/commit/7bed3578ef4990787cd6881c8fc8d5085b617494
On Sat, 8 Jul 2017 21:30:06 -0700
Zac Medico wrote:
>
> Yeah, but it's not going to happen without an EAPI/PMS extension.
> There needs to be a standard way for the package manager to check if
> there has been an upstream change for a given package since the last
> time it was rebuilt.
Something
On Sun, 9 Jul 2017 00:42:46 -0700
Daniel Campbell wrote:
> > - Sets used in profiles cannot have use expansion, versions or
> > anything beyond cat/pkg.
> This would break some set behavior, at least in Portage. Specifying a
> single version (or better, a slot) in a set is less work than addin
On Sun, 9 Jul 2017 05:24:19 -0400
"Walter Dnes" wrote:
> On Sat, Jul 08, 2017 at 09:32:09PM -0400, William L. Thomson Jr. wrote
> > On Sat, 8 Jul 2017 20:27:38 -0400
> > "Walter Dnes" wrote:
> > >
> > > > Though I will have to see what happens if a package is listed in
> > > > more than one
On Sun, 09 Jul 2017 13:36:16 +0200
Michał Górny wrote:
> On nie, 2017-07-09 at 11:29 +0200, Alexis Ballier wrote:
> > You don't seem to get how normalizing and constant
> > propagation/elimination works.
> >
> > Basically, reordering would be:
> > And(list) -> And( forced(list) + free(list) + ma
On nie, 2017-07-09 at 11:29 +0200, Alexis Ballier wrote:
> You don't seem to get how normalizing and constant
> propagation/elimination works.
>
> Basically, reordering would be:
> And(list) -> And( forced(list) + free(list) + masked(list) )
> Or(list) -> Or( ... . )
> etc.
>
> While normalizing
On Sat, Jul 08, 2017 at 09:29:42PM -0400, Rich Freeman wrote
> It is slightly more cruft than a set, but honestly not a great deal so.
The only problem is that you have to maintain ebuilds in an overlay
and run "repoman manifest" every time you create or edit a meta package.
Here's an off-the-w
On Sat, 08 Jul 2017 23:56:07 +0200
Michał Górny wrote:
> On sob, 2017-07-08 at 22:34 +0200, Alexis Ballier wrote:
> > On Sat, 08 Jul 2017 20:44:24 +0200
> > Michał Górny wrote:
> >
> > > On sob, 2017-07-08 at 16:12 +0200, Alexis Ballier wrote:
> > > > On Sat, 08 Jul 2017 11:43:39 +0200
> >
On Sat, Jul 08, 2017 at 09:32:09PM -0400, William L. Thomson Jr. wrote
> On Sat, 8 Jul 2017 20:27:38 -0400
> "Walter Dnes" wrote:
> >
> > > Though I will have to see what happens if a package is listed in
> > > more than one set. I think there is a hierarchy there.
> >
> > I tried "emerge -pv
On nie, 2017-07-09 at 10:29 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 09 Jul 2017, Michał Górny wrote:
> > On nie, 2017-07-09 at 09:22 +0200, Ulrich Mueller wrote:
> > > Second, and more important, introduction of an automatic solver
> > > would inevitably lead to proliferation of REQUIRED_U
> On Sun, 09 Jul 2017, Michał Górny wrote:
> On nie, 2017-07-09 at 09:22 +0200, Ulrich Mueller wrote:
>> Second, and more important, introduction of an automatic solver
>> would inevitably lead to proliferation of REQUIRED_USE in the tree.
>> However, nothing would guarantee that the package m
On sob, 2017-07-08 at 15:47 -0700, Daniel Campbell wrote:
> On 07/08/2017 03:29 PM, Michał Górny wrote:
> > On sob, 2017-07-08 at 15:21 -0700, Daniel Campbell wrote:
> > > On 07/08/2017 02:43 AM, Michał Górny wrote:
> > > > Hi, everyone.
> > > >
> > > > I think the affairs have settled enough and
On nie, 2017-07-09 at 09:22 +0200, Ulrich Mueller wrote:
> > > > > > On Sat, 08 Jul 2017, Michał Górny wrote:
> > Nobody said anything about the next EAPI. The GLEP doesn't say a
> > word about introducing it in a future EAPI.
> > We're adding this as an optional (default off) FEATURE into Portage
On 07/08/2017 06:23 PM, William L. Thomson Jr. wrote:
> On Sun, 9 Jul 2017 01:10:11 +0100
> Ciaran McCreesh wrote:
>
>> On Sat, 8 Jul 2017 19:58:13 -0400
>> "William L. Thomson Jr." wrote:
>>> On Sun, 9 Jul 2017 00:49:57 +0100
>>> Ciaran McCreesh wrote:
On Sat, 8 Jul 2017 19:39:33 -0400
> On Sat, 08 Jul 2017, Michał Górny wrote:
> Nobody said anything about the next EAPI. The GLEP doesn't say a
> word about introducing it in a future EAPI.
> We're adding this as an optional (default off) FEATURE into Portage
> and we'll see how it works. As far as I'm concerned, we can enabl
19 matches
Mail list logo
