On Sat, 26 Jul 2014 14:25:23 + (UTC)
Martin Vaeth wrote:
> Tom Wijsman wrote:
> > Michael Palimaka wrote:
> >
> >> What a great way to kill the distro.
> >>
> >> I can already heat my house with the number of unnecessary rebuilds
> >
> > Do you upgrade @world every hour and thus have it cau
On Sun, 27 Jul 2014 05:30:26 +1000
Michael Palimaka wrote:
> On 07/27/2014 05:21 AM, Tom Wijsman wrote:
> > On Sun, 27 Jul 2014 03:12:07 +1000
> > Michael Palimaka wrote:
> >
> >> On 07/26/2014 07:59 AM, Tom Wijsman wrote:
> >>> On Wed, 23 Jul 2014 22:14:41 +1000
> >>> Michael Palimaka wrote:
On Wed, 30 Jul 2014 15:38:43 +0300
Samuli Suominen wrote:
> That's what I've been trying to point out, people are seriously
> suggesting disabling dynamic deps for race conditions
> It's like fixing one audio driver in the kernel by deleting whole
> ALSA block
It is more like fixing multiple bro
On 30/07/14 14:18, Rich Freeman wrote:
> On Wed, Jul 30, 2014 at 3:38 AM, "Paweł Hajdan, Jr."
> wrote:
>> On 7/30/14, 7:36 AM, Samuli Suominen wrote:
>>> If it's 2-3 packages out of ~300, I'd rather pick them out than
>>> revision bump all ~300 for the 2-3. Or not pick them out at all
>>> and let
On Wed, 30 Jul 2014 07:18:22 -0400
Rich Freeman wrote:
> Sure, but this seems more like a portage bug (or at least a portage
> output bug) rather than a fundamental issue.
>
> After all, there was no true block - just a need for a rebuild.
It's often not possible to produce a decent error messag
On Wed, Jul 30, 2014 at 3:38 AM, "Paweł Hajdan, Jr."
wrote:
> On 7/30/14, 7:36 AM, Samuli Suominen wrote:
>> If it's 2-3 packages out of ~300, I'd rather pick them out than
>> revision bump all ~300 for the 2-3. Or not pick them out at all
>> and let users do the rebuild (which is the obvious answ
On 7/30/14, 7:36 AM, Samuli Suominen wrote:
> If it's 2-3 packages out of ~300, I'd rather pick them out than
> revision bump all ~300 for the 2-3. Or not pick them out at all
> and let users do the rebuild (which is the obvious answer
> to the output you posted)
Peter Stuge pointed it out already
Samuli Suominen wrote:
> let users do the rebuild (which is the obvious answer
> to the output you posted)
Reality check time, Samuli.
Unless emerge says "Your dependencies are b0rk, please rebuild $P to fix it."
that answer is nowhere near obvious.
Watch out with the tunnel vision.
//Peter
On 30/07/14 07:45, Alexander Tsoy wrote:
> В Sun, 27 Jul 2014 14:42:24 +0300
> Samuli Suominen пишет:
>
>> On 26/07/14 15:49, Ciaran McCreesh wrote:
>>> On Sat, 26 Jul 2014 12:41:16 + (UTC)
>>> Martin Vaeth wrote:
hasufell wrote:
> Dynamics deps are already broken, not consistently
В Sun, 27 Jul 2014 14:42:24 +0300
Samuli Suominen пишет:
>
> On 26/07/14 15:49, Ciaran McCreesh wrote:
> > On Sat, 26 Jul 2014 12:41:16 + (UTC)
> > Martin Vaeth wrote:
> >> hasufell wrote:
> >>> Dynamics deps are already broken, not consistently enabled (e.g.
> >>> when subslots are in use
On Tue, Jul 29, 2014 at 3:33 AM, Peter Stuge wrote:
>
> Rich Freeman wrote:
>> This is really the crux of these sorts of issues. It doesn't matter
>> if dependencies are static or dynamic - if you hang onto orphans then
>> you're going to have cruft in your vdb which is going to lead to
>> blocke
On 29 July 2014 19:33, Peter Stuge wrote:
> I think the vdb can and should be updated according to portage changes.
>
> Someone just needs to code it. ;)
>
And an appropriate method for doing this must be decided upon.
And that part entails >70% of the discussion dispute :)
--
Kent
*KENTNL*
Martin Vaeth wrote:
> >> > The user's vardb could then automatically receive the last state of
> >> > the ebuild, before it was removed.
> >>
> >> It doesn't help reliably, either, since the last state of the ebuild,
> >> before it was removed, will be outdated at some point, too.
> >
> > Sorry, I
On Mon, Jul 28, 2014 at 2:50 PM, Martin Vaeth wrote:
>
> In both cases of 6., the user is not even aware that he uses
> long obsolete packages unless portage prints a big fat warning
> for orphaned packages (which currently is not the case.
> Well, at least eix -t will be print a message.)
>
This
On Mon, Jul 28, 2014 at 2:27 PM, Ian Stakenvicius wrote:
>
> The primary underlying problem I see about this is that it doesn't
> force devs to start doing something to the tree that will suddenly
> help make all of the static-deps-only PMs (ie, those that aren't going
> to implement this new hash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27/07/14 08:04 AM, Rich Freeman wrote:
> On Sun, Jul 27, 2014 at 6:43 AM, Kent Fredric
> wrote:
>>
>> In a "no dynamic deps, period" scenario, this just strikes me as
>> 2 flavours of the same weirdness, -r2 and -r1.1 are just equally
>> weird c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/07/14 10:43 AM, Ciaran McCreesh wrote:
> On Mon, 28 Jul 2014 10:30:15 -0400 Ian Stakenvicius
> wrote:
>> On 26/07/14 11:22 AM, Ciaran McCreesh wrote:
>>>
>>> Let's start with the easiest issue: please point us all to the
>>> place where you
On Mon, 28 Jul 2014 10:30:15 -0400
Ian Stakenvicius wrote:
> On 26/07/14 11:22 AM, Ciaran McCreesh wrote:
> >
> > Let's start with the easiest issue: please point us all to the
> > place where you "proved" how dynamic dependencies still work in the
> > face of ebuild removals. Your solution to th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/07/14 11:22 AM, Ciaran McCreesh wrote:
>
> Let's start with the easiest issue: please point us all to the
> place where you "proved" how dynamic dependencies still work in the
> face of ebuild removals. Your solution to this problem will be of
Martin Vaeth wrote:
> > The user's vardb could then automatically receive the last state of
> > the ebuild, before it was removed.
>
> It doesn't help reliably, either, since the last state of the ebuild,
> before it was removed, will be outdated at some point, too.
Sorry, I don't see how. Can yo
Martin Vaeth wrote:
> The user has to put a corrected ebuild into his overlay and must
> reemerge the package (currently, the latter could be skipped with
> dynamic deps).
> In fact, no matter whether you have static or dynamic deps, this is
> the only way to cleanly avoid the problems if you want
On 27/07/14 16:47, Michał Górny wrote:
> Dnia 2014-07-27, o godz. 14:42:24
> Samuli Suominen napisał(a):
>
>> On 26/07/14 15:49, Ciaran McCreesh wrote:
>>> On Sat, 26 Jul 2014 12:41:16 + (UTC)
>>> Martin Vaeth wrote:
hasufell wrote:
> Dynamics deps are already broken, not consisten
On 28 July 2014 09:46, Rich Freeman wrote:
> Then portage could look for any change in state and that would trigger
> a build-less re-merge, which would update vdb with the new state
> (including the new hash).
>
If we're scared about this being worse than what we have, I notice there's
a bunch
On Sun, Jul 27, 2014 at 8:04 AM, Rich Freeman wrote:
>
> Doing this would require having portage cache a hash of whatever
> ebuild it last parsed, and perhaps its eclasses as well if we permit
> revbump-less eclass changes. Then it would have to check for when
> these change, perhaps this might b
Ciaran McCreesh wrote:
> Uh huh, so you add an overlay, and suddenly the dependencies for a
> random subset of your installed packages change in ways that don't in
> any way reflect what you have installed. How is this the desired
> behaviour?
There are several different cases of dependency data w
Dnia 2014-07-27, o godz. 14:42:24
Samuli Suominen napisał(a):
>
> On 26/07/14 15:49, Ciaran McCreesh wrote:
> > On Sat, 26 Jul 2014 12:41:16 + (UTC)
> > Martin Vaeth wrote:
> >> hasufell wrote:
> >>> Dynamics deps are already broken, not consistently enabled (e.g.
> >>> when subslots are i
On Sun, 27 Jul 2014 14:42:24 +0300
Samuli Suominen wrote:
> We just succesfully converted ~300 ebuilds in tree without revision
> bumps from virtual/udev[gudev,introspection,static-libs]
> to virtual/libudev and virtual/libgudev
> Tested it on multiple boxes, went fine.
Testing can't prove that i
On Sun, Jul 27, 2014 at 8:31 AM, hasufell wrote:
>
> I'm eager to hear how you want to make subslots work with dynamic deps.
>
> := gets converted to :${SLOT}/${SUBSLOT} in vardb and this is used to
> trigger the rebuilds.
>
> How do you record the subslot a package was built against in the live t
Samuli Suominen:
>
> On 27/07/14 14:50, hasufell wrote:
>> Samuli Suominen:
>>> On 26/07/14 15:49, Ciaran McCreesh wrote:
On Sat, 26 Jul 2014 12:41:16 + (UTC)
Martin Vaeth wrote:
> hasufell wrote:
>> Dynamics deps are already broken, not consistently enabled (e.g.
>> wh
On 27/07/14 14:50, hasufell wrote:
> Samuli Suominen:
>> On 26/07/14 15:49, Ciaran McCreesh wrote:
>>> On Sat, 26 Jul 2014 12:41:16 + (UTC)
>>> Martin Vaeth wrote:
hasufell wrote:
> Dynamics deps are already broken, not consistently enabled (e.g.
> when subslots are in use)
On Sun, Jul 27, 2014 at 6:43 AM, Kent Fredric wrote:
>
> In a "no dynamic deps, period" scenario, this just strikes me as 2 flavours
> of the same weirdness, -r2 and -r1.1 are just equally weird choices to make
> if the ebuild itself doesn't change at all.
You have a good point here.
With this p
"Paweł Hajdan, Jr.":
> On 7/27/14, 1:42 PM, Samuli Suominen wrote:
>> Only one person said he had to manually build 2 GNOME related packages,
>> simple-scan and something else
>>
>> So, broken? Far from it. More like essential feature.
>>
>> People have just listed some known races dynamic deps hav
On 7/27/14, 1:42 PM, Samuli Suominen wrote:
> Only one person said he had to manually build 2 GNOME related packages,
> simple-scan and something else
>
> So, broken? Far from it. More like essential feature.
>
> People have just listed some known races dynamic deps have, and I take
> those races
Samuli Suominen:
>
> On 26/07/14 15:49, Ciaran McCreesh wrote:
>> On Sat, 26 Jul 2014 12:41:16 + (UTC)
>> Martin Vaeth wrote:
>>> hasufell wrote:
Dynamics deps are already broken, not consistently enabled (e.g.
when subslots are in use)
>>> Just to make it clear: No, dynamic deps a
On 26/07/14 15:49, Ciaran McCreesh wrote:
> On Sat, 26 Jul 2014 12:41:16 + (UTC)
> Martin Vaeth wrote:
>> hasufell wrote:
>>> Dynamics deps are already broken, not consistently enabled (e.g.
>>> when subslots are in use)
>> Just to make it clear: No, dynamic deps are not broken.
> Yes they a
On 27 July 2014 19:16, Martin Vaeth wrote:
> Not at all, it is completely identical to a revision bump:
> If you would use -r2 instead of -r1.1, you also would end up
> in -r1 and -r2 being identical.
> Actually, in both cases, you would *remove* -r1, since -r1 is incorrect
> since it should have
On 27 July 2014 02:12, Martin Vaeth wrote:
>
> Do not forget modification of eclasses which then require mass bumps!
I'm curious what the -r1.1 technique would do here.
I mean, wouldn't that mean you have 2 ebuilds that are identical except for
the '.1' simply due to the eclass change?
That's
On Sun, 27 Jul 2014 03:12:07 +1000
Michael Palimaka wrote:
> On 07/26/2014 07:59 AM, Tom Wijsman wrote:
> > On Wed, 23 Jul 2014 22:14:41 +1000
> > Michael Palimaka wrote:
> >
> >> On 07/23/2014 09:36 AM, Tom Wijsman wrote:
> >>> On Tue, 22 Jul 2014 18:21:00 +1000
> >>> Michael Palimaka wrote:
On Sat, 26 Jul 2014 18:36:27 + (UTC)
Martin Vaeth wrote:
> Ciaran McCreesh wrote:
> >> > * Overlays
> >> Not an issue: Exactly the information of that ebuild
> >> which *would* be used if you reemerge contains
> >> the relevant data.
> >
> > The association between an installed package and "t
On Sat, 26 Jul 2014 12:36:45 -0400
Rich Freeman wrote:
> On Sat, Jul 26, 2014 at 12:02 PM, Ciaran McCreesh
> wrote:
> > On Sat, 26 Jul 2014 15:59:58 + (UTC)
> > Martin Vaeth wrote:
> >> > And what if the match for :=3D is
> >> > incompatible with new dependency atom? Like when you replace
>
On Sat, Jul 26, 2014 at 12:02 PM, Ciaran McCreesh
wrote:
> On Sat, 26 Jul 2014 15:59:58 + (UTC)
> Martin Vaeth wrote:
>> > And what if the match for :=3D is
>> > incompatible with new dependency atom? Like when you replace
>> > 'dev-foo/bar:=3D' with '>=3Ddev-foo/bar-2:=3D' but bar-1 is
>> >
On Sat, 26 Jul 2014 12:28:27 -0400
Rich Freeman wrote:
> Sure, it might cause a "few" unnecessary ebuilds but whether your
> package manager attempts to support dynamic deps or not you'll
> certainly have an up-to-date dependency cache.
VDB is not a cache. This is important.
--
Ciaran McCreesh
On Sat, Jul 26, 2014 at 12:14 PM, Ciaran McCreesh
wrote:
> On Sat, 26 Jul 2014 16:05:58 + (UTC)
> Martin Vaeth wrote:
>> Ciaran McCreesh wrote:
>> > Your solution fails spectacularly in the following ways:
>
>> > * Introduction of :=3D dependencies
>>
>> This is not a "minor update" in depen
On Sat, 26 Jul 2014 16:05:58 + (UTC)
Martin Vaeth wrote:
> Ciaran McCreesh wrote:
> > Your solution fails spectacularly in the following ways:
> >
> > * Ebuild removal
>
> Already discussed as to fail with static deps, too.
Uh, static dependencies don't behave any differently when an ebuild
On Sat, 26 Jul 2014 15:59:58 + (UTC)
Martin Vaeth wrote:
> > And what if the match for :=3D is
> > incompatible with new dependency atom? Like when you replace
> > 'dev-foo/bar:=3D' with '>=3Ddev-foo/bar-2:=3D' but bar-1 is
> > installed.
>
> This is simple: The dependency is not satisfied.
On Sat, 26 Jul 2014 15:40:40 + (UTC)
Martin Vaeth wrote:
> > Let's start with the easiest issue: please point us all to the place
> > where you "proved" how dynamic dependencies still work in the face
> > of ebuild removals.
>
> *Neither* dynamic deps nor static deps solve this problem satisf
On Sat, 26 Jul 2014 15:27:51 + (UTC)
Martin Vaeth wrote:
> Michał Górny wrote:
> > All people with enough knowledge already know that this is
> > technically impossible.
>
> We already discussed in the bug how it *would* be possible,
> just nobody implements it:
>
> Portage would have to us
Dnia 2014-07-26, o godz. 15:27:51
Martin Vaeth napisał(a):
> Michał Górny wrote:
> >
> > All people with enough knowledge already know that this is technically
> > impossible.
>
> We already discussed in the bug how it *would* be possible,
> just nobody implements it:
>
> Portage would have to
Martin Vaeth:
>
> Indeed, it just would just need a little programming.
>
would you like to implement it?
On Sat, 26 Jul 2014 15:11:36 + (UTC)
Martin Vaeth wrote:
> Ciaran McCreesh wrote:
> > Martin Vaeth wrote:
> > The problems are of a different kind. Static dependencies don't do
> > something that you want them to do. Dynamic dependencies are
> > outright broken.
>
> Please, stop your childi
On Sat, 26 Jul 2014 15:04:31 + (UTC)
Martin Vaeth wrote:
> It seems that *you* should take some reading before you
> continue with discussion.
I wrote PMS, the dev manual and a package manager... I understand the
issues involved. If you want to contribute, you should at least read
the spec.
Martin Vaeth:
> Ciaran McCreesh wrote:
>> Martin Vaeth wrote:
>>> hasufell wrote:
Dynamics deps are already broken, not consistently enabled (e.g.
when subslots are in use)
>>> Just to make it clear: No, dynamic deps are not broken.
>>
>> Yes they are.
>
> Could you please stop your c
Dnia 2014-07-26, o godz. 15:01:46
Martin Vaeth napisał(a):
> Ciaran McCreesh wrote:
> > Martin Vaeth wrote:
> >> The idea is to act "as usual", just to skip unnecessary phases...
> >
> > So someone adds optional selinux support to a package, and then you end
> > up with selinux being "on", desp
On Sat, 26 Jul 2014 14:57:20 + (UTC)
Martin Vaeth wrote:
> > This is a technical discussion
>
> Exactly. So instead of writing such pointless personal attacks,
> you should give technical arguments.
The technical reasons that dynamic dependencies can never work have
already been explained. H
On Sat, 26 Jul 2014 14:46:42 + (UTC)
Martin Vaeth wrote:
> Yes, both concepts have problems.
The problems are of a different kind. Static dependencies don't do
something that you want them to do. Dynamic dependencies are outright
broken.
> Since neither solution is perfect, why choose the on
Martin Vaeth:
> Ciaran McCreesh wrote:
>>> But, OK, so I will use your strawman to prove
>>> how static deps are broken:
>>
>> This is not broken. This is exactly what is supposed to happen
>
> "It's not a bug it's a feature"
> Of course, one can always close the eyes when faced
> with problems.
Ciaran McCreesh:
> On Sat, 26 Jul 2014 14:33:38 + (UTC)
> Martin Vaeth wrote:
>> Ciaran McCreesh wrote:
No. PMS does not specify which dependency information has
to be taken.
>>>
>>> Yes it does. Please read PMS, and do not guess as to what it says.
>>
>> Looking for /var/db/pkg gav
On Sat, 26 Jul 2014 14:33:38 + (UTC)
Martin Vaeth wrote:
> Ciaran McCreesh wrote:
> >> No. PMS does not specify which dependency information has
> >> to be taken.
> >
> > Yes it does. Please read PMS, and do not guess as to what it says.
>
> Looking for /var/db/pkg gave exactly one hit:
> Th
Dnia 2014-07-26, o godz. 14:09:44
Martin Vaeth napisał(a):
> Alexander Berntsen wrote:
> >
> > 1. Improve dynamic-deps. This is, as Michał pointed out earlier in
> > this thread a pipe dream.
>
> Not necessarily. Just somebody with enough knowledge in
> portage and python has to fix it.
> The
Dnia 2014-07-26, o godz. 14:02:29
Martin Vaeth napisał(a):
> Alexandre Rostovtsev wrote:
> >
> > rdepends-add is easy to implement [...] Deletion is trickier [...]
> >
> > The point is to *not* clean up these entries for months/years.
>
> So, essentially, you want the developer to do part of CV
On Sat, 26 Jul 2014 14:09:44 + (UTC)
Martin Vaeth wrote:
> > PMS defines a static dependency model
>
> No. PMS does not specify which dependency information has
> to be taken.
Yes it does. Please read PMS, and do not guess as to what it says.
--
Ciaran McCreesh
signature.asc
Description:
On Sat, 26 Jul 2014 13:41:34 + (UTC)
Martin Vaeth wrote:
> The idea is to act "as usual", just to skip unnecessary phases...
So someone adds optional selinux support to a package, and then you end
up with selinux being "on", despite not having it, and then another
package depends upon your pa
El sáb, 26-07-2014 a las 12:00 +, Martin Vaeth escribió:
[...]
> Probably there are many more examples than 1.-4, but I hope
> that the point becomes clear: Whenever packages split, merge,
> or can substitute each other, dependency changes are necessary,
> and rebuilds caused by these are unnec
On Sat, 26 Jul 2014 13:16:13 + (UTC)
Martin Vaeth wrote:
> But, OK, so I will use your strawman to prove
> how static deps are broken:
This is not broken. This is exactly what is supposed to happen, and it
is exactly what *does* happen some of the time with dynamic
dependencies too.
--
Ciar
On Sat, 26 Jul 2014 13:00:31 + (UTC)
Martin Vaeth wrote:
> Both, dynamic and static deps are broken.
> They are broken in different ways, but both are broken.
You keep using that word. I do not think it means what you think it
means.
--
Ciaran McCreesh
signature.asc
Description: PGP signa
On Sat, 26 Jul 2014 12:54:08 + (UTC)
Martin Vaeth wrote:
> Ciaran McCreesh wrote:
> > Jeroen Roovers wrote:
> >> On Mon, 21 Jul 2014 23:06:07 +0200
> >> Pacho Ramos wrote:
> >> > Maybe this could be solved by having two kinds of revisions:
> >> > - One would rebuild all as usually (for exam
On Sat, 26 Jul 2014 12:41:16 + (UTC)
Martin Vaeth wrote:
> hasufell wrote:
> > Dynamics deps are already broken, not consistently enabled (e.g.
> > when subslots are in use)
>
> Just to make it clear: No, dynamic deps are not broken.
Yes they are.
> What is broken is that portage does not
On Sat, 26 Jul 2014 12:32:20 + (UTC)
Martin Vaeth wrote:
> Ciaran McCreesh wrote:
> > User installs foo-1.1-r1
> > Developer makes foo-1.1-r1.1
> > foo-1.1* is removed from the tree
> > User syncs
>
> How is this different from your suggestion
> (which you *claim* to be non-broken):
>
> Use
On Fri, 25 Jul 2014 05:44:34 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> How long have dynamic-deps been around? Since EAPI-0? Because if
> so, that interpretation must be incorrect, since EAPI-0 was defined
> as portage behavior at the time, and AFAIK, no EAPI since then has
> been appro
On Wed, 23 Jul 2014 22:14:41 +1000
Michael Palimaka wrote:
> On 07/23/2014 09:36 AM, Tom Wijsman wrote:
> > On Tue, 22 Jul 2014 18:21:00 +1000
> > Michael Palimaka wrote:
> >
> >> What a great way to kill the distro.
> >>
> >> I can already heat my house with the number of unnecessary rebuilds
On Tue, Jul 22, 2014 at 4:06 PM, Martin Vaeth wrote:
> ...but by introducing all the additional complications Ian
> has mentioned. More precisely: What happens if new dependencies
> are introduced which are not satisfied?
> One has to face it: Portage must not just silently "update" the
> database
On 07/23/2014 09:36 AM, Tom Wijsman wrote:
> On Tue, 22 Jul 2014 18:21:00 +1000
> Michael Palimaka wrote:
>
>> What a great way to kill the distro.
>>
>> I can already heat my house with the number of unnecessary rebuilds
>
> Do you upgrade @world every hour and thus have it cause excessive heat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22/07/14 04:51 PM, Andreas K. Huettel wrote:
> Am Dienstag 22 Juli 2014, 22:40:03 schrieb Ulrich Mueller:
>>> On Tue, 22 Jul 2014, Martin Vaeth wrote:
>>> PF has to be filled correctly, of course: The versions foo-1
>>> and foo-1-r0 are identi
On Tue, 22 Jul 2014 18:21:00 +1000
Michael Palimaka wrote:
> What a great way to kill the distro.
>
> I can already heat my house with the number of unnecessary rebuilds
Do you upgrade @world every hour and thus have it cause excessive heat?
If I upgrade every X weeks they become much more coo
Am Dienstag 22 Juli 2014, 22:40:03 schrieb Ulrich Mueller:
> > On Tue, 22 Jul 2014, Martin Vaeth wrote:
> > PF has to be filled correctly, of course:
> > The versions foo-1 and foo-1-r0 are identical according to PMS
> > and should thus lead to the same $PF.
>
> This is not so. These versions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22/07/14 20:40, Martin Vaeth wrote:
> If there is interest, I can post my patches so far. Where?
If you think these patches are useful for Portage, please send them to
dev-port...@gentoo.org.
- --
Alexander
berna...@gentoo.org
https://secure.plai
On 22/07/14 20:11, Ciaran McCreesh wrote:
> On Tue, 22 Jul 2014 19:03:16 +0200
> Sven Vermeulen wrote:
>> As someone who regularly adds in dependencies without bumping (adding
>> USE=selinux dependencies to the proper SELinux policy) because that
>> would trigger lots of totally unnecessary rebui
On Tue, 22 Jul 2014 19:03:16 +0200
Sven Vermeulen wrote:
> As someone who regularly adds in dependencies without bumping (adding
> USE=selinux dependencies to the proper SELinux policy) because that
> would trigger lots of totally unnecessary rebuilds:
Er... You do realise that doing that with d
On July 22, 2014 11:25:05 AM CEST, Pacho Ramos wrote:
>El mar, 22-07-2014 a las 10:32 +0200, Kristian Fiskerstrand escribió:
>[...]
>> I find it somewhat curious that the difference between ~arch and
>> stable hasn't been brought up in this discussion yet. IMHO a user on
>> ~arch should expect a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22/07/14 09:39, Martin Vaeth wrote:
> Pacho Ramos wrote:
>>
>> Maybe this could be solved by having two kinds of revisions: -
>> One would rebuild all as usually (for example, -r1...) - The
>> other one would only regenerate VDB and wouldn't cha
El mar, 22-07-2014 a las 10:32 +0200, Kristian Fiskerstrand escribió:
[...]
> I find it somewhat curious that the difference between ~arch and
> stable hasn't been brought up in this discussion yet. IMHO a user on
> ~arch should expect a higher number of rebuilds, it _is_ after all
> testing, where
On 22/07/14 11:21, Michael Palimaka wrote:
> On 07/22/2014 07:52 AM, Alexander Berntsen wrote:
>> To sum up: My vote is disable dynamic-deps. And I would be happy to
>> apply a patch that does this with the information I have today.
> What a great way to kill the distro.
>
> I can already heat my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/22/2014 10:21 AM, Michael Palimaka wrote:
> On 07/22/2014 07:52 AM, Alexander Berntsen wrote:
>>
>> To sum up: My vote is disable dynamic-deps. And I would be happy
>> to apply a patch that does this with the information I have
>> today.
>
>
El mar, 22-07-2014 a las 07:39 +, Martin Vaeth escribió:
> Pacho Ramos wrote:
> >
> > Maybe this could be solved by having two kinds of revisions:
> > - One would rebuild all as usually (for example, -r1...)
> > - The other one would only regenerate VDB and wouldn't change the
> > installed fi
84 matches
Mail list logo
