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