Re: Debian-Alpha port ideas...please read (long)
On Wed, 29 Oct 1997, Bdale Garbee wrote:
> Hmmm. You are, of course, right. I'm struggling a bit with the notion of
> freezing our development source tree, though. As a cross-platform package
> maintainer, a hard freeze would be a pain... a "soft freeze" is probably
> manageable.
I realised once my head hit the pillow that a "soft freeze" would be a bit
more flexible and preferable for obvious reasons. More on this in a sec.
> What I really notice is that we need to get a consistent set of libaries and
> compiler tools in place...
Absolutely. What I've seen so far is that alot of our compiler tools and
libraries were compiled before most of us joined the project and, thus,
patches aren't available for recompilation of some of the stuff (gcc,
libg++, and ldso to name a few). Since these are "hardcore" packages and
heavily needed, we should probably try to track down or redo those patches
so we can recompile such things at will if needed.
On a related note, what do you think we should do about the "g" libs?
Part of me is heavily tempted to drop the "g" designation on the Alphas at
least for compatibility, but I also realise that this is a generally bad
idea since I can foresee other arch maintainers compiling their own stuff
soon (via fakeroot) on the Alpha and making such decisions would
complicate the process of getting that to happen. In short, I don't know
of a good and easy answer. We could try to "nuke" the libs directory and
get everything compiled ASAP....just a thought.
> I'd have agreed with you a couple of weeks ago. I'm fully up-to-date hamm
> on my dual-P6 SMP box now, with kernel 2.1.57, and the machine is nice and
> solid again.
That's good news :) A pat on the back should go to all of us as well
since I think we've made a ton of progress in the past few months on our
side as well :)
> : * ease of installation on ANY Alpha hardware
> Good goal, hard to achieve unless we can identify folks who actually use
> each of the machine types to help test and document things. The UDB's are
> cute, but they aren't the whole picture.
Agreed about the difficulty to achieve regarding hardware specifics.
That's why I was asking/polling the list recently to find out hardware
specifics from everyone. If we can get a list of hardware that we've
tested things on, it would bring us one step closer to getting this
accomplished.
> : * great documentation that's easy to follow for installation procedures
> : on all Alpha hardware
> Ditto.
I'll try to free up a Jaz disk this coming weekend (time allowing with
Halloween and all). Once I do this, I should be able to accomplish a
fresh install on my UDB without harming my existing setup at all. I have
noticed that the RedHat FAQ and instructions are lacking when it comes to
MILO and such, so we should probably resolve that issue as well in our
documentation.
> : * a unified and stable source tree for developers to work on porting
> : (patches should be portable throughout platforms, fyi)
> How about we constrain this to just stabilizing the libraries and development
> tools? If we do that, we can choose whether to build new versions of app
> packages or not as we wish with minimal impact.
True and a good idea. If we can get our libs and dev tools consistent,
then rebuilding other packages should be pretty easily accomplished.
> : Developers, please monitor this list and that site for these reports daily
> : (if possible) since our only hope for stability and problem resolution is
> : via feedback.
> I watch the list daily, but check the bug page much less frequently.
I know the feeling. I keep an eyeball on five debian lists and haven't
been checking the bug page as often as I should. I've resolved recently
to keep up with the page, though, since it is a good way for the less
vocal on the list to report problems.
> : even though *MY* personal system is stable
>
> Ok, here's a thought. How about posting the output of "dpkg --list" here
> once a week or something, with a few comments about anything that seems like
> it isn't working well. I may be wrong, but I'm thinking this might help
> communicate what we know is working... I've been on a jihad to run only
> current libraries and rebuild rather than force dependencies... but I don't
> actually live on my alpha (it's just a toy/learning tool/porting platform
> for me), so I don't stress a lot of the system as much as others perhaps do.
Not a bad idea. I would say that once a week might be a tad too frequent
since most of our systems don't change appreciably in a week, but the
concept is sound. I have also taken your "jihad" route regarding
libraries, but my weakness right now is the X stuff (I'm running
half-and-half right now..."g" libs with non-g xbase...not a good idea
generally).
As for me, I pretty much do all of my work on my UDB. It's a hobby box,
but it still eats up my free time more than my other machines (ok, I
actually do spend more time playing hockey games on my Win machine, but
you get the point :P). I have a "bo"-running Pentium at work that does my
official duties work stuff, but all programming I do for that system
starts on the Alpha for portability.
> : In short, we desperately need documentation right now rather than package
> : availability.
> We need the set of packages that are currently available on master in .deb
> form to be consistent and functional, and dselectable. Once we achieve that
> state, we need documentation. Once we have that, we can go back to trying to
> increase the available package count and/or track the x86 clan...
Good point. I would say that we should probably get the base and devel
directories dselectable first, followed quickly by libs and x11. These
are the most used and requested and offer us a good starting point to work
on. Once we get that, it's all a matter of rebuilding what isn't updated,
starting documentation, and then tracking the x86 folks.
> : I also feel I should mention that I am not seeking any "power" position by
> : promoting the above ideas.
> No sweat.
Had to throw that in since I was definitely preaching from the soap box :)
Chris
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: