Re: [gentoo-dev] Re: Avoiding rebuilds

[Brian Dolbec]

On Mon, 28 Jul 2014 05:49:07 +0000 (UTC)
Martin Vaeth <martin@×××××.de> wrote:

> hasufell <hasufell@g.o> wrote:
> > Ulrich Mueller:
> >>
> >> I wonder if it wouldn't be saner to leave our revision syntax
> >> untouched.
>
> As already mentioned, -r1.1 is only one of several possible ways
> how to achieve the same aim; I am not speaking in favour for a
> particular method.
> The -r1.1 method has the advantage of being simple and transparent
> to the user and developer.  Other approaches have other advantages:
>
> >> Instead, one could introduce a variable INSTALL_VERSION that would
>
> (It would have to be a variable stored in the metadata/ cache
> and thus also would only work with a new API, but these are only
> technical details.)
>
> >> default to ${PVR} but could be set to the version of a previous
> >> ebuild instead. The PM could compare it against INSTALL_VERSION in
> >> the VDB and skip build and installation if versions match.
>
> It should be a list and have empty default (*never* including the
> version itself), but these are also technical details.
> This solution would have the advantage that you could specify
> *full* versions and thus have even more fine-grained control when
> recompilations are necessary. One could also allow specify version
> ranges, slots, overlays, etc., perhaps even make the behaviour
> dependent of USE-flags, as you already mentioned, all
> similarl to current DEPEND syntax.
>
> The disadvantage is that it is slightly more work than -r1.1,
> less transparent, and easily overlooked to remove for a version bump,
> causing issues like these:
>
> > It will probably also cause confusion for comaintainers and
> > collaborators, especially when INSTALL_VERSION points to a version
> > that has already been removed.
>
>

I haven't had the energy to read all the mails over all the dynamic
deps thread...

the -r1.1 syntax has been in use by the prefix since early in it's
existence.  I haven't kept track, but they may have finally done away
with it.

There are many other problems with using that syntax, namely most other
tools are not compatible with it, so more than just portage needs to be
modified.  Adding that syntax to ebuilds will cause disruptions and bugs
for years to come.

So, please, forget about this syntax as a viable solution.

-- 
Brian Dolbec <dolsen>