Re: [gentoo-dev] [PATCH vcs-snapshot] Use ${WORKDIR}/${P} rather than ${S} to support ${S} overrides.

[Michał Górny]

On Mon, 04 Jun 2012 22:47:33 +0200
hasufell <hasufell@g.o> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/04/2012 10:06 PM, Michał Górny wrote:
> > On Mon, 04 Jun 2012 21:26:00 +0200 hasufell <hasufell@g.o>
> > wrote:
> >
> >> But minetest in sunrise for example which has two different
> >> repos, one for the engine, one for the data. It's currently split
> >> in two, but I guess I will merge those soon.
> >
> > Why? Is there a good reason to merge two repos into one ebuild?
> > Does upstream guarantee that the releases will always be synced?
> > Does it benefit users?
>
> In this case yes. They are released with the exact same tags as you
> can see in those ebuilds.

But could there be a case where fixing a build in the engine wouldn't
require data being rereleased? Or having the tag pointing to the same
commit it was pointing to previously?

If upstream splits a package, and supports building/installing the two
parts separately, we should do that as well.

> >> It would also enable me to use gtk-youtube-viewer and
> >> youtube-viewer in one ebuild with vcs-snapshot eclass while
> >> adding a gtk useflag (currently split too). Otherwise I will have
> >> to fix it on my own again.
> >
> > Once again: does it benefit user? Or just does it imply that
> > starting or stopping to use gtk part requires user to rebuild the
> > whole thing?
>
> Eclasses do not benefit any user. They benefit developers. I would
> simply do similar stuff on my own in the ebuild instead of using
> vcs-snapshot eclass then.

Does splitting the package benefit user? Gentoo has a long history of
overusing USE flags out of laziness. If upstream explicitly allows
building GTK+ part separately of core, we shouldn't merge that. We
should rather be grateful they don't force us to end up like Fedora,
splitting build tree into smaller packages.

> > I really don't mind the logic. I'm just aware that it is a little
> > late to introduce such a destructive change, especially that you
> > yourself mentioned that it will break existing ebuilds.
>
> So? We fix it.

As I see the purpose of vcs-snapshot, it is more likely to be used in
various overlays than in the gx86 tree. I don't believe you are able to
fix *all* the occurrences.

And while we're at it, changing eclass APIs doesn't benefit users nor
developers. It can cause breakages which will hurt users, and forces
developers to do more work when they don't have time to.

> > I will be happy to implement it if you can get more approval for
> > that change. Or else we should consider jumping with the eclass to
> > -r1 while it isn't widespread too much.
>
> I don't see the point in bumping it, because it's not widespread.

There are still more packages that it breaks than those which it would
actually benefit. But I like the idea of using filename for the
location. Could you look up PMS for me to see if it's guaranteed that
it will be preserved in $A?

-- 
Best regards,
Michał Górny