The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2016-07-24 23:59 UTC.
Removals:
app-cdr/dvd95 20160724-11:25 mgorny 37d88cd
app-portage/g-ctan 20160724-10:45 mgorny abca5f5
dev-libs/vdk
On Sun, 24 Jul 2016 12:17:56 +0200
Michał Górny wrote:
> So what's the alternative? Design another eclass where ebuilds will
> fail just the same because people will ignore the more explicit
> requirement just the same as they do ignore the API?
Sometimes you don't need a "new path", you just ne
On Sun, 24 Jul 2016 10:17:24 +0200
Chí-Thanh Christopher Nguyễn wrote:
> > Then ebuilds will fail just the same
>
> No. Before, ebuilds would maybe display an upgrading message when
> they shouldn't, or vice versa. Now the eclass dies on them.
As a side note: die-ing in anything after merging
Chí-Thanh Christopher Nguyễn schrieb:
I don't say it is a correct use of versionator.eclass. I just say it has
become (unintentionally) part of the API, and therefore is subject to the
rules about changing APIs in eclasses.
Actually, after reading those rules[1] again, it would be enough to fix
> On Sun, 24 Jul 2016, Michał Górny wrote:
> There is no such thing as 'unintentional API'. API is what's
> described. If you rely on internals, random undefined behaviors
> or whatever, it's not a part of the API.
Like memcpy(3) direction?
Ulrich
pgpaBBWxp15uE.pgp
Description: PGP signatu
On Sun, 24 Jul 2016 12:17:56 +0200
Michał Górny wrote:
> But that's a social problem that could easily solved by more
> proactive retirements, and not a good API design point.
You need some trained and payed PR people to correct your writings
before they go to press or you will never be elected
Michał Górny schrieb:
You are changing the API of versionator.eclass, even if it was unintentional
API.
There is no such thing as 'unintentional API'. API is what's described.
If you rely on internals, random undefined behaviors or whatever, it's
not a part of the API.
Well there is the API
On Sun, 24 Jul 2016 10:17:24 +0200
Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
> > So, to summarize we shouldn't fix existing code because people did
> > assume accepting invalid parameters was fine.
>
> You are changing the API of versionator.eclass, even if it was unintention
On Sun, Jul 24, 2016 at 10:17:24AM +0200, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
> > So, to summarize we shouldn't fix existing code because people did
> > assume accepting invalid parameters was fine.
>
> You are changing the API of versionator.eclass, even if it was unintent
Ciaran McCreesh schrieb:
On Sun, 24 Jul 2016 10:17:24 +0200
Chí-Thanh Christopher Nguyễn wrote:
Then ebuilds will fail just the same
No. Before, ebuilds would maybe display an upgrading message when
they shouldn't, or vice versa. Now the eclass dies on them.
This attitude that invisible fai
On Sun, 24 Jul 2016 10:17:24 +0200
Chí-Thanh Christopher Nguyễn wrote:
> > Then ebuilds will fail just the same
>
> No. Before, ebuilds would maybe display an upgrading message when
> they shouldn't, or vice versa. Now the eclass dies on them.
This attitude that invisible failures (which don't
Michał Górny schrieb:
So, to summarize we shouldn't fix existing code because people did
assume accepting invalid parameters was fine.
You are changing the API of versionator.eclass, even if it was unintentional
API.
Then ebuilds will fail just the same
No. Before, ebuilds would maybe disp
On Sun, 24 Jul 2016 00:17:21 +0200
Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
> > Ensure that proper number of parameters is passed to each versionator
> > function; die otherwise. This prevents the functions from proceeding
> > with undefined behavior when mis-called.
>
> You
On Sun, 24 Jul 2016 10:05:23 +0300
Andrew Savchenko wrote:
> I agree with you, but REPLACING_VERSIONS has nothing to do with
> such recovery.
Yes, it does. Specifically, what we want is for developers to get into
the habit of writing safe, clean code, even if they think they don't
need to care ab
Hi,
On Sun, 24 Jul 2016 03:00:40 + (UTC) Duncan wrote:
> Andrew Savchenko posted on Sun, 24 Jul 2016 00:30:39 +0300 as excerpted:
>
> > Do we ever had such case like multiple versions of the same
> > single-slotted package installed or recorded as installed in the real
> > world? I'm not sure
15 matches
Mail list logo