Re: [cobalt-users] Have SUN stopped supporting XTR?

[Travis Ogdon <togdon@xxxxxxxxxxxxxx>]

Ryan Verner wrote:

> Debian was the first distro to actually package 4.2 (4.2.1 is definitely in
> unstable).  I remember there was some font incompatibility somewhere with 4.2,
> and as a result Debian was the only distrib that showed the problem. 
> Everybody was blaming Debian.

Ok, so picking on X wasn't really fair on my part. Debian is the only distro
that packages several of the port targets for X, some of which the X developers
and testers don't have access to, so until Debian gets around to packaging it no
one really knows if it will work. Also, I started using debian before there was
an apt, which was well before there were three branches. I still think of
unstable as what they're currently calling testing. I often forget that there's
a really unstable version out there too. 


> Said that though, we dont have to use their packages.  Its quite trivial to
> create our own - so we can do pretty much what we want.  My plan is to use the
> debian framework (base, debian tools, packaging) with our own stuff.

It would be nice to use as much of Debian stable as possible. We may want to
pick 10 packages or so at most that are worthy to track on our own and just
defer everything else to them. Since these are headless boxes that primarily
serve as web/ftp servers I know which packages I'd vote to package on our own...


> > You're still going two years between 'apt-get dist-upgrades' though.
> 
> So?  I don't see the problem with this...

Only that if we were to look solely to Debian for our package sources that
unless there's a problem with a package in the two years in between releases
we'd end up getting stuck with stale packages unless we wanted to track testing
or unstable. Gerald had mentioned relying on the distro for most of the heavy
lifting... I'd rather that we rely on them for the heavy lifting of the base,
but that we repackage the stuff that's important to us. In all reality it's
possible to do both. If we were to take Debian as the base you could eitehr
stick with straight up stable, or add in a couple of extra lines in your
/etc/apt/sources.list to get more recent versions of stuff. 

A typical /etc/apt/sources.list file might look like:

deb http://http.us.debian.org/debian/ stable main non-free contrib
deb-src http://http.us.debian.org/debian/ stable main non-free contrib
deb http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free
deb-src http://non-us.debian.org/debian-non-US stable/non-US main contrib
non-free

deb http://security.debian.org/ stable/updates main contrib non-free

deb http://somewhere.org/ stable/qbalt main


A stable raq with a few unstable packages tracked might look like:

deb http://http.us.debian.org/debian/ stable main non-free contrib
deb-src http://http.us.debian.org/debian/ stable main non-free contrib
deb http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free
deb-src http://non-us.debian.org/debian-non-US stable/non-US main contrib
non-free

deb http://security.debian.org/ stable/updates main contrib non-free

deb http://somewhere.org/ testing/qbalt main
deb http://somewhere.org/ testing/qbalt-extras main


And A more bleeding edge raq might look like:

deb http://http.us.debian.org/debian/ unstable main non-free contrib
deb-src http://http.us.debian.org/debian/ unstable main non-free contrib
deb http://non-us.debian.org/debian-non-US unstable/non-US main contrib non-free
deb-src http://non-us.debian.org/debian-non-US unstable/non-US main contrib
non-free

deb http://somewhere.org/ unstable/qbalt main
deb http://somewhere.org unstable/qbalt-extras main


In all three cases you'd be looking to Debian to maintain the core, and us to
maintain the kernel and any cobalt specific packages. Additionally in the second
and third example you'd be relying on us for some of the "important" packages of
various things like Apache. The stable/qbalt would run against stock debian
Apache and whatnot, the testing and unstable would require that the more recent
versions of software be installed (Apache for instance has had minor changes in
the config file over the last several years, we'd need to accomdate for those).
Dependencies would be handled by us offering a newer .deb. IF we all got flaky
at some point and dropped off the face of the earth no one would lose much since
as soon as Debian's package was newer than ours it would be installed instead.

This all may be a lot simpler than I was thinking. If we're able to install
debian via bootp (instructions like these make me think that it may not be that
hard: http://www.linux-debian.de/howto/debian-mips-woody-install.html) and we're
able to get a working driver for the lcd we're really 3/4 of the way there. For
those who don't need or want a GUI, we're done. For those that do... well... :)

-- Travis