[Mentalunix-developers] New Path

[Clinton E. <men...@cr...>]

I have really been thinking about this(and looking at code), and I 
think it is time to scrap the idea of a new distribution from 
scratch. It would be pointless to do that, when all of the groundwork 
has already been laid. Why do something over when it has already been 
done a few dozen times? I see no point. But, I do see a point in 
channeling your energy to make the existing better. So, I propose 
that we do a "fork" of debian -- repackage a few programs, use the 
majority of the existing ones, add a new installer, help to improve 
the debian software(if you take something, it is only fair that you 
give back), and add mpkg. 


Ok, the first thing to get to is what to do with mpkg? I see mpkg as 
not being a package manager with its own format, but rather be a 
manager that can install other pacakges, and help to maintain 
syncronized databases between pacakge formats. In essence, if I 
install a deb with mpkg, mpkg will generate a virtual rpm that 
provides certain files and install it into the rpm database. And, 
mpkg needs to become the best tool for distribution maintenence.
Basically, make pacakging debs really easy(maybe a gtk/curses program 
to help get someone started / make maintence of the package even 
easier?), and to make building a distrinution easy. Take this 
fictional command:

mpkg --rebuilt-tree --target=i586 --source-tree=/home/me/source --
output-tree=/home/me/bin/586/

What would that command do? It would take a tree of debian source 
packages, and maybe rpm/slp/slackware packages(later), and rebuild 
them for your target, and dump the compiled packages in the output 
tree directory. Now, one way to make these easier to code is to make 
all mentalunix/new_name packages use a common extension for source 
pacakges - .sdeb, instead of the one used in the debian 
archives(tar.gz). It would make it easier for the program to tag 
files as debs and tag files as autoconfigure packages(which 
eventually it should be able to configure and install with one 
command instead of 3, more on this later). Instead of unpacking them 
to see what it is, it could just check the 
extension(string.substr(".sdeb") using the STL strings). The whole 
thing would be a nice program sitting on top of libdpkg / librpm / 
zlib / mlib(mpkg library so other programs could use the functions, 
and make it so mpkg would have cleaner code). 
Being able to rebuild a distribution for any platform you want is a 
great power. The only large problem I see is getting the build 
depending to work -- either have the program un gzip / untar every 
file and check its build depends, have a nice build depends db(this 
can be done with the .dsc file I think) at the root of the source 
tree(and have mpkg apt-get all of the pacakges it needs pre build), 
or you can just hope the user has the files he/she needs.

Making mpkg make packaging more approachable needs to be a large 
goal. It should be a lot easier for anyone to pacakge their 
software..so the upstream authors could do more packaging, and we 
could have more maintaners. A nice way to convert autoconf / automake 
packages to debs would be cool, but that would require looking into 
the shell scripts and parsing and stuff to get the build / runtime 
depends. The only way around this problem IMHO is to make it a lot 
easier to make pacakges from scratch. Have a Gtk+ GUI program that 
lets a user select packages that it relies on during build and 
runtime from a pop up list(actually an interface to apt-cache), and 
just give it an autoconf package, and an output sdeb(it would just 
strip all of the autoconf stuff and rewrite it with the Debian/rules 
and new autoconf stuff). I know this would help a lot of people 
become package maintainers.

Why did I abandon the idea of writing mpkg from scratch? I discovered 
apt / dpkg, and I fell in love. Dpkg is a nice piece of packaging 
software, and apt makes it even nicer. So, why rewrite it, when you 
can build a tool that uses dpkg, and can take advantage of apt. The 
only trouble with apt is that it only modifies the deb database, and 
only install debs(or rpms, but you can't have both), so maybe it 
would need some code added to call mpkg --resync(resync the 
databases) after install stuff, or actually using mpkg instead of 
dpkg(mpkg's syntax will be dpkg syntax + extended options..but there 
needs to be a focus on adding the high level features, then filling 
in the gaps for the 1.0 release; basically keep dpkg around for a 
while)..using mpkg and not dpkg(once we get a nice 100% backwards 
compatable with dpkg release) would allow apt to install lots of 
formats. So, instead of rewriting all of the package code, we just 
have to write some of the stuff people haven't really done yet, and 
use the existing stuff people have already done. This saves us time, 
and allows us to get a lot more done, faster.


Instead of writing an entirely new distribution, adding on to an 
existing one(debian would be a lot easier to add on to than mandrake 
would ever have been) allows us to focus on the little pieces missing 
from existing distributions instead of focusing on putting the pieces 
already there in. An example: the desktop. Sure, gnome and kde are 
nice, but are they truly Integrated Desktop Enviroments? Sure, if you 
use Gtk/QT programs, but what about older programs, and programs that 
don't use them? Do they change apperance when you change your theme? 
No! Do they behave with the desktop enviroment like the other 
programs? No! So, we could focus on bringing the "IDEnv"(Integreated 
Desktop ENViroment) to become a reality. And xfce is a key tool in 
this.

Ok, if you have ever used xfce, you know it is cool. It is like 
gnome, but with a few less features, and a really different way of 
thinking. But, that doesn't matter. What does matter is it can modify 
xresources..so, if you change your theme in xfce, all of the non-Gtk 
programs will change colors(nothing like what gtk can do, just simple 
pallette modification). Now, since I know kde2 can use gtk 
themes(how?), I don't think it would be to hard to add support for 
controlling how QT apps look too. So, we use xfce. We make a nice 
looking desktop, and create panel menus with the programs users often 
use. We add desktop support to XFTree, and call it a day. Plus, with 
its XFGnome module...yay! It can do GNOME. The windowmanager may look 
a bit old, but it really isn't that bad. Users can use any wm they 
want with it anyway(some like to use E with it). 

Graphical login should be the default, but the installer should allow 
this to be changed. Using gdm would be good, and the Default session 
would be linked to the xfce session. Use the mentalunix gtk theme on 
the login manager, and have a nice mentalunix logo as the picture it 
uses. That wouldn't be too hard.

Provide helix gnome. Use their packages, not debians. Yes, they have 
some dependeny issues, but they aren't really that bad, and if one 
does prove troublesome, default back to the debian one. Or, we can 
see how gnome in woody / sid progresses and move to that. Some people 
will want gnome, not xfce.

Make linuxconf work nicely with Debian. Really hard to do, not really 
a great priority.

Repackage certain pieces of software to make them more integrated 
with the distribution. Such as xfce. Also, making pacakges use 
debconf for any install time configuration is a must. 



The installer should be nice and graphical  with a text based 
fallback. Basically, the choices for installer should be(the first 
stage installer should detect which one can run):

Gtk-frame buffer installer
Native X server install
VGA16 X installer
ncurses installer

The installer should be like any other but with these addons:
- Provide a bunch of different kernels and detect what kernel would 
be best for the user(SMP?/arch/SCSI or IDE?).
- Advanced configuration of hardware in custom mode(as an option to 
the user). One of my friends had trouble configuring his burner. So, 
provide a kernel wil scsi emulation, and configure the kernel / 
config files to allow uage of the burner(either kill ATAPAI support 
100%, or append="/dev/drive=ide-scsi" in the lilo config..if we don't 
use grub). Same goes for things like digital cameras(if one is 
detected if they can, offer to configure the gtk camera program to be 
able to use it) and scanners(if they can be detected, offer to 
configure SANE). For printers that can give an ID back to the 
computer(2 way parallell port..my ancient printer sends back BJC-250 
when the parralell port code is initialized), have the installer 
autoconfigure the printfilter. If it can't be id'd, then let the user 
confiure.


That is all I can type for now. My eyes hurt. Please post comments.

---------------------
ASCII ART
*********
        *
*********
"Ain't it l33t?"
All views expressed are IMHO.
Because MHO is better than yours.
unknown_lamer