Anthony Towns schrieb am Donnerstag, den 19. Oktober 2006: > On Wed, Oct 18, 2006 at 12:59:20PM +0200, Michael Schmitz wrote: > > Regarding a solution for m68k beyond etch - I'd prefer to keep m68k > > snapshots on a basis like you mentioned: > > * have m68k be in unstable, and have it have its own "testing-like" > > suite of some description > > + keeps the arch alive > > - some work to keep m68k-testing in sync with real testing > > needed > > - doesn't have real releases > > - may not have security support > > > So, if someone could give me a brief intro as to how testing migration of > > 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. > > 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 > 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.
*snip* > 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. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
