Re: [gentoo-dev] Re: don't rely on dynamic deps

[Ian Stakenvicius]

-----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
> <axs@g.o> 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 this problem will
>>> be of great benefit to all of us.
>>>
>>
>> This is something I personally don't understand.  If an ebuild
>> for a package installed on the system has been removed from the
>> tree, but newer and/or older ebuilds exist in the tree, then the
>> installed package can #1 only be trusted in accordance with the
>> ebuild copy enbedded in VDB (that i get), BUT, #2 should be
>> forced to either upgrade or downgrade so that it matches what
>> *is* in the tree anyhow, and that's done via a standard ${PV}
>> comparison that should happen regardless of whether static or
>> dynamic deps methods are in place.
>
> But you can't run pkg_prerm unless a package's dependencies are
> satisfied. How do you know what those dependencies are, if you
> don't use VDB and if the ebuild isn't there?
>
> (This is a real issue: see the botched ruby-config switch.)
>

Yes, that's an issue -- I thought the pkg-*rm case had to do with the
ebuild's phase definition itself being (or not being) updated, I
haddn't thought about it in terms of dependencies being unsatisfied.

Keeping every single dependency around and valid just so that pkg_*rm
can completely cleanly seems like so much overkill, though..
Unfortunately the only way I see around that would be to have some
form of reduced subset, which would mean yet-another-*DEPEND, and we
all know that's not going to happen..

I wonder if there would be a way to somehow add restrictions to
pkg_*rm phases s.t. either REPLACED_BY_VERSION's dependencies must be
satisfied at the time the phases are run, or REPLACED_BY_VERSION is
empty and the in-VDB ones must be satisfied.  It'll be a pain for
dev's to make sure their stuff works within these restrictions, and
the likeliness of repoman being able to enforce any sort of QA on this
probably so close to zero it doesn't matter, but i'm not seeing
another way.

(outside of forcing the in-vdb deps to always remain satisfied, of
course; however i think the dependencies-get-upgraded-first approach
which is generally necessary for all but PDEPEND can still cause
breakage here too, no??)



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPWbpMACgkQ2ugaI38ACPBkdwEAsPg3Gu4I3LuXfBuvrxfGJ3D6
sv/ZOROo0a0xPzQ8IZgA/icJDURR+a0mrvT2fwSzXNfd+azvaaKxjNOcRPHOcSYE
=YElO
-----END PGP SIGNATURE-----