ok, that makes more sense now.

what happened to the suggested solution a few emails ago that in this
case the user should just create their own dummy-sources ebuild of
sufficiently high version and keep it in their local overlay tree?
 
while this is a legitimate grip of the portage system because it is not
convienent to do this, portage "does" have what i see as a solution, its
just not as convenient as one might want it.

so the question is should portage change to make this easier as per
suggested below.  i vote no because if we make a "dummy-XXX" then one
could argue that every package should have a dummy-* build for it. in
the long run i'm sure some user will write the dummy-* build for most
packagse in portage and that would significantly grow (everyone agree?)
the size of the tree as a solution that is for convenience.

dave
On Fri, 2003-07-25 at 22:34, Georgi Georgiev wrote:
> On 25/07/2003 at 21:26:31(-0600), Dave Nellans used 1.4K just to say:
> > I agree with brad, I proposed the emerge inject solution was how this
> > problem was intended to be dealt with but couldn't quite make sense of
> > the reason this didn't work from the thread.
> > 
> > could someone possibly clearly give the arguement against injecting
> > again for us slow people?
> 
> The problems as I get them, are:
> 
> - Injecting the sources, would work, but it would require reinjecting every
>   newer version, or else an "emerge -u" would upgrade the version for us, when
>   for example upgrading a package that depends on the sources.
> 
> - Injecting a sufficiently big, non-existing version would not work, because an
>   emerge -u (even -U) would downgrade the version to the highest available,
>   i.e. it would install a version.
>  
> It seems that having a dummy-sources whose version does not change would solve
> this problem.
-- 
Dave Nellans
http://lucy.wox.org/~dnellans/
dnellans@cs.utah.edu