Re: testing to be implemented on ftp-master
On Tue, Dec 19, 2000 at 03:01:33PM +1000, Anthony Towns wrote:
> All it means is that if PHP4 doesn't build on arm anymore (as long as
> it did *once*) then we have to make a choice: either stick with the old
> version everywhere, or don't distribute PHP4 on arm. testing normally
> sticks with the old version, unless someone deletes the old PHP4 from
> unstable, at which point it'll update everyone (else).
Which is a bit problematic on things like security updates.
> If it's just impossible to get the new version of something to build on
> an architecture anymore, there are two solutions that testing won't complain
> about at all:
>
> * remove the package entirely from that architecture
>
> * fork the source package at the old version, and have, say
> glibc_2.2-6.dsc and glibc2.1_2.1.3-14.dsc, which are each
> used for (only) the appropriate architectures.
Are we willing to use (A) more often? If a package develops a
critical security hole, and does not build on that architecture, can we
justify removing it? I suppose that it would be the best option.
> > > Everything's already in the pool, it doesn't have to be in the pool/
> > > directory on the archive for that. Files in the proposed-updates/
> > > directory can and are in potato itself, files in woody/ can and are in
> > > sid, and heck, files in woody/ are even no longer in woody.
> > I sense the potential for endless months of confusion over that last...
>
> Yes, but it's better than having every mirror have to do 18GB of updates
> in a single day... (Even 2.2r2 was a 1GB pulse)
Certainly. Are we planning to phase it out the way we've phased out
symlinks to previous stable distributions?
> > > I'm not really sure I see the point of this: it doesn't particularly
> > > help with the release (since they won't be released), and unreleased
> > > architectures aren't particularly reliable for users no matter what you do
> > > (or they'd be released!), so...
> > But it does make it easier to work out what the problems are for a
> > future release, I'd think.
>
> Well, if it's just statistics you're after, that can be arranged. They're
> already done for the released archen in sid, adding the unreleased ones is
> easy.
It's not statistics that I'm after but usage. Just because testing
isn't fully synced on an architecture doesn't mean that seeing and
using what would be there wouldn't be useful. For instance, if we try
to autobuild testing - that's impossible as it stands now, nothing will
hit testing until it is recompiled. You have to have an installable
testing distribution on the architecture you're building for in order
to get the right dependencies.
Although, that's a bad example, as I think autobuilding testing would
be inappropriate. Still, just for daily use by people actively working
on the port, testing would be very useful. I'd like to see some
unreleased architectures with Packages files saying which WOULD be in
testing for that architecture.
On Tue, Dec 19, 2000 at 12:38:27AM -0500, Sam Hartman wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <dan@debian.org> writes:
> Daniel> The more I hear about this feature, the more I love and
> Daniel> hate it. It'll get package building in shape real, real
> Daniel> quick - but it's impractical, I think. Consider the state
>
>
> Can't you drop arm from the architecture line and drop the arm package
> if you fail to resolve the problem?
Removing seems like a more useful solution; just dropping it from the
architecture line would leave the old version dangling, and would
require extreme amounts of human intervention - the status quo would
then be to not build it, making it extremely unlikely to ever be fixed.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
Reply to: