hasufell posted on Fri, 25 Jul 2014 15:44:47 + as excerpted:
> Sounds like that would be an interesting gentoo project. But afais PMS
> doesn't really specify how binary packages should look like, so we will
> hit incompatibility problems there as well.
AFAIK binpkgs are purely an individual
On 25/07/14 23:09, Ian Stakenvicius wrote:
> On 25/07/14 04:41 PM, Michał Górny wrote:
>> Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius
>> napisał(a):
>
>>> +REQUIRED_USE="heimdal? ( !mit-krb5 ) + mit-krb5? (
>>> !heimdal )"
>
>> Did you mean:
>
>> REQUIRED_USE="^^ ( heimdal mit-krb5
Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted:
> Hey all.. So, putting aside for now how much of a mess this would be to
> implement in the virtuals' ebuilds themselves, what do people think of
> changing the virtuals so that they contain an entry in IUSE for each
> prov
El vie, 25-07-2014 a las 21:18 +0100, Ciaran McCreesh escribió:
> On Fri, 25 Jul 2014 22:12:53 +0200
> Pacho Ramos wrote:
> > Ah, ok, I was wondering why REQUIRED_USE was implemented then :/, I
> > guess it was for simplifying ebuilds?
>
> It was a historical mistake: originally we were going to
El sáb, 26-07-2014 a las 08:05 +, Duncan escribió:
> Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted:
>
> > Hey all.. So, putting aside for now how much of a mess this would be to
> > implement in the virtuals' ebuilds themselves, what do people think of
> > changing t
El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
> On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
> > On 07/25/14 15:50, Pacho Ramos wrote:
> > > El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió:
> > >> On 07/25/14 15:28, Pacho Ramos wrote:
> > >>> T
El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió:
> El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
> > On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
> > > On 07/25/14 15:50, Pacho Ramos wrote:
> > > > El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Bas
Dnia 2014-07-26, o godz. 08:05:32
Duncan <1i5t5.dun...@cox.net> napisał(a):
> Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted:
>
> > Hey all.. So, putting aside for now how much of a mess this would be to
> > implement in the virtuals' ebuilds themselves, what do people t
Duncan posted on Sat, 26 Jul 2014 08:05:32 + as excerpted:
> Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted:
>
>> Hey all.. So, putting aside for now how much of a mess this would be
>> to implement in the virtuals' ebuilds themselves, what do people think
>> of chan
Michał Górny posted on Sat, 26 Jul 2014 10:53:21 +0200 as excerpted:
> USE_EXPAND are global by definition. We ought fight with the abuse of
> USE_EXPAND rather than make another abuse legitimate. Especially that
> you're going to increase a lot of new variables quickly for no really
> good reason
On 07/26/14 04:44, Pacho Ramos wrote:
El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió:
El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
On 07/25/14 15:50, Pacho Ramos wrote:
El vie, 25-07-2014 a las 15:
Am Samstag, 26. Juli 2014, 10:44:26 schrieb Pacho Ramos:
> El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió:
> > El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
> > > On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
> > > > On 07/25/14 15:50, Pacho Ramos wr
Ian Stakenvicius wrote:
>
> The only need for EAPI change that I can see is to allow non-integer
> revision values
A change of the version/-revision format certainly requires
an EAPI change; one must also define rules how to compare
these versions, etc. (despite it is obvious, here).
Please be a
Rich Freeman wrote:
> 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 silen
El sáb, 26-07-2014 a las 06:22 -0400, Anthony G. Basile escribió:
[...]
> 1) I don't think we need to drop to exp if we do this right.
>
> 2) I like this plan. Its not that we'll drop the whole arch to ~ at
> once but trim at our discretion. Less chance of breaking everything.
>
Looks like we
On 26/07/14 13:22, Anthony G. Basile wrote:
> On 07/26/14 04:44, Pacho Ramos wrote:
>> El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió:
>>> El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
> On 07/2
On 07/26/14 07:36, Pacho Ramos wrote:
El sáb, 26-07-2014 a las 06:22 -0400, Anthony G. Basile escribió:
[...]
1) I don't think we need to drop to exp if we do this right.
2) I like this plan. Its not that we'll drop the whole arch to ~ at
once but trim at our discretion. Less chance of breaki
El sáb, 26-07-2014 a las 07:47 -0400, Anthony G. Basile escribió:
> On 07/26/14 07:36, Pacho Ramos wrote:
> > El sáb, 26-07-2014 a las 06:22 -0400, Anthony G. Basile escribió:
> > [...]
> >> 1) I don't think we need to drop to exp if we do this right.
> >>
> >> 2) I like this plan. Its not that we
On 07/26/2014 11:09 AM, Johannes Huber wrote:
> Am Samstag, 26. Juli 2014, 10:44:26 schrieb Pacho Ramos:
>> El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió:
>>> El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile
El sáb, 26-07-2014 a las 13:57 +0200, Manuel Rüger escribió:
[...]
> +1 from ruby.
>
> How do we solve keyword requests?
> https://bugs.gentoo.org/show_bug.cgi?id=477648 is ~ 12 months and hasn't
> seen any reply from the ppc* teams.
> https://bugs.gentoo.org/show_bug.cgi?id=497396 ~ 6 months
> ht
Tom Wijsman wrote:
>
> Useless triggers are the problem; why are the rev bumps needed, why are
> dependencies forgotten, ...?
It is not only about *forgotten* dependencies:
It is whenever something is restructured, a new project appears, etc.
Some examples:
1. Package foo/bar splits into foo/ba
> On Wed, 23 Jul 2014, Tom Wijsman wrote:
> Using an extension like -rX.Y seems odd; at the very least, I think
> an incremental variable or something along that line in the ebuild
> would work better.
It would also account for changes in eclasses, which any scheme bound
to the ebuild's filen
On 07/26/14 07:59, Pacho Ramos wrote:
El sáb, 26-07-2014 a las 13:57 +0200, Manuel Rüger escribió:
[...]
+1 from ruby.
How do we solve keyword requests?
https://bugs.gentoo.org/show_bug.cgi?id=477648 is ~ 12 months and hasn't
seen any reply from the ppc* teams.
https://bugs.gentoo.org/show_bug.
Tom Wijsman wrote:
>
> Assuming dynamic dependencies don't exist, another package would still
> depend on the USE flag in the vdb; the only way to force that USE flag
> dependency to go away is with an unnecessarily rebuilding rev bump, as
> without it it would complain that the USE flag doesn't e
On Sat, Jul 26, 2014 at 7:56 AM, Pacho Ramos wrote:
>
> I guess we will need to wait for the next Council to officially decide
> to do this as it will be a big change for ppc* users :/ (I remember
> their action was needed for the move to testing of some arches and the
> "package-by-package" propo
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):
User installs foo-1.1-r1
Developer makes foo-1.1-r2
foo-1.1* is removed from the tr
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.
What is broken is that portage does not use them consistently.
It would be a rather bad idea to change policy just because of
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 Sat, 26 Jul 2014 10:53:21 +0200
Michał Górny wrote:
> USE_EXPAND are global by definition.
Naah. They're global by a Portage configuration file limitation. In the
old days, USE flags were global too...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
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
Maxim Kammerer wrote:
> On Tue, Jul 22, 2014 at 12:25 AM, Michał Górny wrote:
>> The funny thing is, almost none of the Gentoo developers even know that
>> slot operators disable dynamic dependencies completely in portage.
>
> So *that's* why I now have to change RDEPENDs in both the source
> ebu
Am Samstag, 26. Juli 2014, 10:44:26 schrieb Pacho Ramos:
> > But, moving ppc* to exp wouldn't lead us to likely break their tree?
> > (because we wouldn't get any dependency issue even with "base"
> > packages...)
>
> I was thinking in this plan:
> - Get a list with all packages stable on ppc
> -
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 example, -r1...)
>> > - The other one would only regenerate VDB and wouldn't c
> On Sat, 26 Jul 2014, Martin Vaeth wrote:
> Quite the opposite, PMS claims that one cannot rely on
> anything stored in /var/db
Where does it say so?
Ulrich
pgpF949UyfMJV.pgp
Description: PGP signature
Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos:
> I guess we will need to wait for the next Council to officially decide
> to do this as it will be a big change for ppc* users :/ (I remember
> their action was needed for the move to testing of some arches and the
> "package-by-package" pr
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
Ciaran McCreesh wrote:
> Ian Stakenvicius wrote:
>> The thing about -rX.Y is that it allows this new-dynamic-deps thing
>> to act like a regular rev bump to any PM that doesn't bother to
>> implement it (or dynamic deps for that matter). Instant
>> backwards-compatibility is a handy feature.
>
>
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
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
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
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
El sáb, 26-07-2014 a las 08:23 -0400, Rich Freeman escribió:
> On Sat, Jul 26, 2014 at 7:56 AM, Pacho Ramos wrote:
> >
> > I guess we will need to wait for the next Council to officially decide
> > to do this as it will be a big change for ppc* users :/ (I remember
> > their action was needed for
El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió:
> Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos:
>
> > I guess we will need to wait for the next Council to officially decide
> > to do this as it will be a big change for ppc* users :/ (I remember
> > their action was ne
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/07/14 04:05 AM, Duncan wrote:
> Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as
> excerpted:
>
>> Hey all.. So, putting aside for now how much of a mess this
>> would be to implement in the virtuals' ebuilds themselves, what
>>
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
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
On 07/26/14 09:28, Pacho Ramos wrote:
El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió:
Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos:
I guess we will need to wait for the next Council to officially decide
to do this as it will be a big change for ppc* users :/ (I re
Hello,
app-admin/chef and its related packages are currently maintainer-needed.
So if you're using chef on Gentoo, this is your chance to step up!
These packages have some restricting dependencies (e.g.
https://bugs.gentoo.org/buglist.cgi?quicksearch=app-admin%2Fchef&list_id=2433248
signature
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
El sáb, 26-07-2014 a las 09:37 -0400, Anthony G. Basile escribió:
> On 07/26/14 09:28, Pacho Ramos wrote:
> > El sáb, 26-07-2014 a las 14:55 +0200, Andreas K. Huettel escribió:
> >> Am Samstag, 26. Juli 2014, 13:56:02 schrieb Pacho Ramos:
> >>
> >>> I guess we will need to wait for the next Council
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
Patrick Lauer wrote:
>
> Without binpkg support I'd feel the need to hack it up, just to get things
> fast enough.
binpkg support has some severe problems currently, anyway.
I already described it in the bug, but since perhaps the
description was not clear, I repeat it here:
I regularly build bi
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
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
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
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:
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
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
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
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
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
On 07/25/2014 08:49 PM, Ian Stakenvicius wrote:
> Hey all.. So, putting aside for now how much of a mess this would be
> to implement in the virtuals' ebuilds themselves, what do people think
> of changing the virtuals so that they contain an entry in IUSE for
> each provider that can satisfy it?
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
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
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.
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
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
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
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
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
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
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
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.
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
Michał Górny wrote:
>
> Python is irrelevant here. Our dependencies are USE-conditional
You are right, I overlooked this.
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:
>
> 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
Martin Vaeth:
>
> Indeed, it just would just need a little programming.
>
would you like to implement it?
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
On Sat, Jul 26, 2014 at 10:44:26AM +0200, Pacho Ramos wrote:
> El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió:
> > El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
> > > On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
> > > > On 07/25/14 15:50, Pacho Ramo
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
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: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
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: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.
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 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
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
I know I'm replying to my own message, but I do have a concern about
this that I want to ask about.
When a stable request is filed for a package, it is filed for all
architectures which have the ~arch keyword for the package and are
marked stable or dev in profiles.desc.
If an arch wants to stay
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
Am Samstag, 26. Juli 2014, 18:20:11 schrieb William Hubbs:
> I know I'm replying to my own message, but I do have a concern about
> this that I want to ask about.
>
> When a stable request is filed for a package, it is filed for all
> architectures which have the ~arch keyword for the package and
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: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 07/27/2014 02:20 AM, William Hubbs wrote:
> I know I'm replying to my own message, but I do have a concern about
> this that I want to ask about.
>
> When a stable request is filed for a package, it is filed for all
> architectures which have the ~arch keyword for the package and are
> marked
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 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, Jul 26, 2014 at 06:31:50PM +0200, Andreas K. Huettel wrote:
> Am Samstag, 26. Juli 2014, 18:20:11 schrieb William Hubbs:
> > I know I'm replying to my own message, but I do have a concern about
> > this that I want to ask about.
> >
> > When a stable request is filed for a package, it is
On 07/27/2014 03:19 AM, William Hubbs wrote:
> If an arch team isn't going to honor a stable request, shouldn't they
> remove themselves from it and say so?
>
> Also, if an arch team does that, does that mean we don't have to file
> stable requests for that arch on future versions of the package?
1 - 100 of 111 matches
Mail list logo
