Re: packages missing from sarge

[Vincent.McIntyre@csiro.au]

> > Proposal: allow 1.3.7 into sarge, on the following basis -
> >  * woody has 1.3.0, ie it's used by current users of stable
>
> This doesn't deal with questions of possible bit rot (which your tests
> address to some extent, but not completely).  It also doesn't provide a
> smooth upgrade path for users of sarge==testing who have a no-longer-present
> version of apt-proxy 1.9 installed on their systems.  While support for

urk. yes, that is a problem.

> upgrades within testing are not "release-critical" because there's no
> release involved, I'd rather that sarge users have apt-proxy show up under
> "obsolete" than be caught running an unsupported, *newer* version with no
> indication of trouble; and I feel strongly enough about this to not let
> 1.3.7 back in via t-p-u.

okay. That clarifies the situation for me.

> That means that if people want apt-proxy 1.3 in sarge, it should go through
> unstable with an epoch, possibly kicking 1.9 out to experimental for the
> duration.

If people pursued this path, would it make sense to rename the packages
to apt-proxy-shell and apt-proxy-python (both would Provide: apt-proxy)
to avoid future RCs in one implementation clobbering the other?
This is all starting to sound like "etch" work to me. However I'll shut
up now and defer to the maintainers.

Thanks for your reply
Vince