Re: m68k not a release arch for etch; status in testing, future plans?
> > > So, if someone could give me a brief intro as to how testing migration of
I really ought to have dropped the 'brief' there :-)
> > > packages works, and what would be needed to modify britney, I'd welcome
> > > it.
> >
> > The idea, presumably, would be to have a separate britney instance just
> > for m68k. That would mean that testing itself wouldn't be held back by
> > any m68k problems, but would also mean that m68k wouldn't necessarily
> > be held back by non-m68k problems -- eg, if something doesn't build on
> > sparc, it could be updated for testing-m68k but not testing proper.
I don't think we'll hit that problem - my guess is we'd try to follow
testing as close as possible. If sparc holds back something that would be
OK for m68k, it still won't go into testing, and adding something too fast
might cause problems down the line. Maybe it's no problem at all; we can
decide that later.
> > The problem comes for things like transitions and so forth, where britney
> > can't work out that it's okay to upgrade foo as long as libfoo and libbar
> > are upgraded at the same time -- that often needs someone to follow the
> > britney output and manually note down the things that work. Sometimes
That's the point where I'll need a more elaborate introduction to britney.
The 'hints' is some file where you define preferred solutions for these
conflict situations, did I get that right?
> > for large transitions you can't do it completely smoothly and something
> > will need to break -- and a human needs to choose which is the least
> > bad thing to have break, so britney will need some help there too.
> I have some small experience with britney and hints from an old dead project
> :). But if its just manpower for the m68k britney I volounteer for help.
Much appreciated. Maybe you can give me some help to get started.
> > Note that without a stable release, you'll need to maintain some way to
> > deal with people who want to install on m68k -- you can't just rely on
> > them installing stable and upgrading to testing.
> Indeed, we would need some kind of semi-official relase for m68k, maybe a
> little bit later. But I don't see a big problem there. Thats just a matter of
> work and there are some people willing to do that.
That's what I meant by snapshots off m68k-testing. I'm a bit unclear on
the distinction between a snapshot of testing taken at a time when not too
much is broken and most of the packages have been built, and a release.
Michael
Reply to: