On Wed, 5 Sep 2012 08:25:54 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Tue, 4 Sep 2012 19:23:51 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > > > The 'checking out' language for src_unpack() sounds like it > > > assumes a DVCS such as mercurial or git. What about cvs or svn, > > > where fetching is also checking out? (This is probably a trivial > > > thing to clear up, though.) > > > > They either stay with src_unpack() or do 'cvs up' in src_fetch() > > and just copy files over in src_unpack(). Anyway, that's what they > > do now -- update the copy in distfiles/cvs-src and then copy it. > > This doesn't work if we have, for example, foo:1 and foo:2 both using > the same SCM repository, but different branches. Much as we'd like to > pretend that everyone uses Git, we can't really ignore this case... > > So we have to decide: do we make the src_fetch copy the data somewhere > after all, or do we require that eclasses do something obscene to > avoid this? Eclasses have to handle themselves, if we are supporting this. There's no point in bloating the solution for 1 theoretical package on 1000 which doesn't even exist. And yes, it is *very* unlikely that someone uses a slotted live ebuild with two branches being meaningful and managed in the same repo. Even if such thing exists, it is broken anyway because you can't say that re-fetching the branches back and forth is a correct solution. And it breaks existing tools anyway. Well, even I doubt eclasses need to do something obscene. The need for that is so small that I believe if someone was crazy enough, he could just set an appropriate storedir in ebuild. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
