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
Peter Stuge wrote:
>
> This suggests another data model bug to me: that dependencies belong
> to the dependent packages, rather than to dependency providers.
Sometimes it is this way, sometimes the opposite.
It would not be natural to associate to a huge library like openssl
the packages which us
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
Ian Stakenvicius wrote:
>
> Keeping every single dependency around and valid just so that pkg_*rm
> can completely cleanly seems like so much overkill, though..
It is not only overkill, it would require a merging strategy which
AFAIK portage currently does not use and which would lead to blockers
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
Peter Stuge wrote:
> 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.
>
> S
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
Peter Stuge wrote:
> Martin Vaeth wrote:
>> In fact, no matter whether you have static or dynamic deps, this is
>> the only way to cleanly avoid the problems if you want to keep a
>> package installed which is not maintained anymore:
>> *You* must maintain it. There simply is no magic which can av
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
Duncan <1i5t5.dun...@cox.net> wrote:
>
> 1) Foo incorrectly deps on bar
> 2) User installs foo with the incorrect dep
> 3) Foo maintainer detects the error
> 4) Due to dynamic-deps, portage depcleans bar.
> 5) Since nothing in the tree needs bar, it is removed.
> 6) Finally, foo is removed from tre
Paweł Hajdan, Jr. posted on Sun, 27 Jul 2014 16:56:17 +0200 as excerpted:
>> One thing I would question in that table is "applied immediately (but
>> can break hard when dynamic-deps stop working))." How can dynamically
>> removing an "unused dependency" cause something to break, setting aside
>>
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
Rich Freeman wrote:
>
> I'd think that a change in repository should probably be treated like
> a revbump.
I agree. At least, currently eix already shows [U] in such a situation,
and IMHO it would be wise if portage would suggest to upgrade/downgrade
then, too. But this is a topic which is rather
Michał Górny wrote:
>
> Consider the following:
>
> 1. A depends on B, both are installed,
>
> 2. dependency on B is removed, emerge --depclean uninstalls B thanks
> to dynamic-deps,
>
> 3. B is treecleaned (nothing depends on it),
>
> 4. old version of A is removed (user doesn't update it yet), t
Kent Fredric wrote:
> 1. User installs Foo
> 2. Gentoo needs to change what Foo depends on
> 3. Gentoo simply tweaks the ebuild and doesn't bump [A]
> 4. User syncs.
> 5. Subsequent emerges see dependencies from [A] which are fixed and works
>in the interim
> 6. A gets removed.
> 7. User syncs
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
hasufell wrote:
>>> Ciaran McCreesh wrote:
>
> This looks like a private lesson
*If* there is a corresponding passage in PMS, it seems to be
somewhat hidden (as I pointed out) and certainly many others
haven't found this, either.
(As the eix maintainer, I know PMS probably better than many
in th
Kent Fredric wrote:
> 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 du
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 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 07/23/2014 09:36 AM, Tom Wijsman wrote:
> On Tue, 22 Jul 20
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
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 "the ebuild it came
> from" doesn't work correctly when overlays around.
I
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:
>>>
What a great way to kill the distro.
I can already heat
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
hasufell wrote:
> Martin Vaeth:
>
>> Indeed, it just would just need a little programming.
>
> would you like to implement it?
I thought about it, but unfortunately, I am currently
(and for a long period) so busy with my job
that this is not realistic - I did not even find the
time to implement m
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
Ciaran McCreesh wrote:
> Your solution fails spectacularly in the following ways:
>
> * Ebuild removal
Already discussed as to fail with static deps, too.
> * Overlays
Not an issue: Exactly the information of that ebuild
which *would* be used if you reemerge contains
the relevant data.
> * Int
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.
Michał Górny wrote:
>
> This is only one of the issue.
Not all cases need to be solved: If a developer decides
that no revbump is not necessary, he should not have a
too problematic change...
> And what if the match for :=3D is
> incompatible with new dependency atom? Like when you replace
> 'de
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
Ciaran McCreesh wrote:
> 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 childish behaviour
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?
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 use dynamic deps throughout,
using the data stored in /var/db only to find out
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
Michał Górny wrote:
>
> Python is irrelevant here. Our dependencies are USE-conditional
You are right, I overlooked this.
Michał Górny wrote:
>
>> 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", despite not having it, and then anot
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.
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 childish behaviour.
You prove nothing be repeating claims which had just been di
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
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", despite not having it, and then another
> package depends upon your package w
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 childish behaviour?
>> Wh
Ciaran McCreesh wrote:
>
> At this point, I think it would be most helpful towards us reaching a
> conclusion if you agreed to refrain from commenting further until
> you've understood the problem at hand.
In other words: After I disproved all your wrong arguments,
you try repeatedly to ignore my
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 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.
> and it
> is exactly what
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
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:
The assertion that this is *not* part of PMS.
The section on dependencies is on
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
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 cause excessive heat?
>
> If I upgrade every X weeks they become much more cool an
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:
Kent Fredric wrote:
>
> So we'll probably need a repoman check that is smart enough to know "X is
> modified" and compare the DEPEND fields with the previous incarnation prior
> to commit, and then at very least, warn people doing `repoman full` that
> they've modified the dependencies, and that 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 problem is that in gentoo there seems to be currently
nobody with these skills
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 CVS/git's job,
namely keeping a history of changes in a compressed format,
ke
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
Michał Górny 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 files (for example, -r1.1)
>
> I'm afraid it couldn't. The major problem
Pacho Ramos wrote:
>
> Isn't there a way for PMs to know that they need to not rebuild full if
> user has 1.1-r1 *installed* in his system and pretends to update to
> -r1.1?
This is exactly the idea of -r1.1, and this (at least the check)
already works in the code snippet I had sent to the portag
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
Ciaran McCreesh wrote:
>
> Wrong. The reason everything is such a mess at the moment is precisely
> because we've accumulated so much "good enough" and "not thinking your
> cunning plan all the way through"
There *is* no perfect solution.
And the reason why everything is such a mess at the moment
Rich Freeman wrote:
>>
>> User installs foo-1.1-r1
>> Developer makes foo-1.1-r1.1
>> foo-1.1* is removed from the tree
>> User syncs
>
> An updates-like mechanism would help here, since the updates could
> persist longer.
Unfortunately, this is not an option:
I assure you that you do not want to
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
Ciaran McCreesh wrote:
>> User installs foo-1.1-r1
>> Developer makes foo-1.1-r2
>> foo-1.1* is removed from the tree
>> User syncs
>>
>> In fact, the result is completely the same
You completely ignored this essential point:
The result is completely the same, and you are
just arguing with a stra
1 - 100 of 144 matches
Mail list logo
