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

[Ian Stakenvicius]

-----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
> <kentfredric@×××××.com> 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 proposal we have three kinds of ebuild changes: 1.  Those
> that do not involve any revbump. 2.  Those with a "minor" revbump
> (ie -r1 -> -r1.1). 3.  Those with a normal revbump (ie -r1 ->
> -r2).
>
> What is the purpose of allowing the first?  Presumably that should
> be used in even more limited circumstances than a minor revbump, so
> why allow it at all?  Why not just make an in-place change
> equivalent to a minor revbump and ditch the minor revbump entirely?
> Devs would still need to distinguish between what requires a
> revbump and what does not.
>
> 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 be stored in the metadata
> to speed things up.
>
> You could view such an approach as being equivalent to just
> sticking a ".hash" on every ebuild in the tree as a minor revision
> tag, so that any change triggers a minor revision.  The only
> difference between that and the proposal that I can see is that the
> minor revisions would be unordered.  However, if we go with the
> theory that defective ebuilds get removed immediately then there is
> no point in ordering minor revisions because there will only be one
> in the tree at any time for a given major revision, so the package
> manager couldn't take advantage of any information conveyed by
> ordering.
>
> This probably isn't too different from what portage is doing
> already, except: 1.  Portage is only looking for dependency changes
> when it has another reason to look closely at the ebuild - it has
> no mechanism to detect that an ebuild changes, and this would add
> one. 2.  We don't have any clear policies today on when ebuilds
> should be revbumped or not as the result of things like dependency
> changes, and this would cause us to make some.
>
> The fact that this isn't a big change does concern me that it may
> not fix all of the underlying problems.  However, some of those
> problems might not actually have clean solutions other than never
> committing mistakes in the first place.  For example, if a prerm
> dependency was missing then removing the ebuild can potentially
> fail whether you use dynamic deps or not until it is satisfied.
>

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-changed-so-re-evaluate-ebuild method)
suddenly work in a more consistent fashion.  IIRC, the very first post
of this thread was a reminder to dev's to revbump so that static-deps
behaviour is more correct/consistent.


However, if we put something into the next EAPI about this and make it
a requirement for all PMs (although I have no idea how we would roll
this out; maybe make it a profile-level requirement instead of an
ebuild-level one, if there is such a thing??) then it would become
much less of an issue..  Mind you, we need to solve all of the
problems first and make sure PMS documents all of the requirements in
an appropriately complete and ambiguity-preventing manner that
everyone agrees with..  Easy, right? :)





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

iF4EAREIAAYFAlPWlfYACgkQ2ugaI38ACPApTwD9H+PX4f1XGtauwbjfXczPqAYf
yBqDW9MOwIlWPCqeu6IA/ipySyWxA/J12RSuLTNyj98li9Qmeq0GLR37KSZ2Cc/p
=05lZ
-----END PGP SIGNATURE-----