-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 21/07/14 05:06 PM, Pacho Ramos wrote:
> El lun, 21-07-2014 a las 20:55 +0100, Ciaran McCreesh escribió:
>> On Mon, 21 Jul 2014 21:53:04 +0200 "Andreas K. Huettel"
>> <dilfri...@gentoo.org> wrote:
>>> Revision must be bumped when the on-disk files installed by
>>> the ebuild are changed. Nothing about dependencies.
>>>
>>> This has been policy for a LONG time, and we're not going to
>>> change it overnight just because you protest.
>>
>> Policy used to be that you'd do a revbump when you wanted users
>> to reinstall stuff, and you wouldn't otherwise. The only
>> complication is that sometimes you want users to reinstall stuff
>> so that there's accurate dependency information available, rather
>> than because something has changed.
>>
>
> 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)
>
> But I am not sure if it could be viable from a "technical" point
> of view :(
>
>
eww, no. Using ${PVR} to detect how portage should update things
would be asking for trouble, imo. Besides, I don't think detection of
when to just update VDB is the issue. The main issue that I see is
- -how- VDB should be adjusted based on what changes are made to the
ebuilds. For instance, if minimum versions of deps are adjusted
in-place, should vdb be updated to match? what happens if the minimum
version of the currently-installed dep is below the new one? etc. etc.
Also, in theory an EAPI bump with nothing else changing should be
re-generatable in the VDB, but i have a gut feeling (no evidence, just
a feeling) that going from say, EAPI2 to EAPI5 without doing some of
the phase functions again (ie 'merge', maybe there are others that can
affect VDB?) will result in a different VDB from a regular rebuild.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlPObO0ACgkQ2ugaI38ACPCerQEAgTgQOvCDl0dbB5sOOZ4diBNs
cheQR18XFo7MsVBX3uUA/0zP1cAiWy1zAF+crrfCC42krtvGmSSiU4JG0dFo4452
=iNmo
-----END PGP SIGNATURE-----
