If you haven't been added to be part of the project, please email (ce940@hotmail.com) me with your username if you have one, if not signup for one and then send it to me. Also, I am still trying to figure out how to assign tasks to people, once I firgure that out, then you will be assigned tasks.
What do people want to work on, reply to this as a thread.
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think we should start discussing the whole package management issues.
This is definitely one of the most important issues. It could also make MaxLinux standout in the crowd of distributions.
I'm not sure if we should create our own package manager. It poses two major problems:
1. Development effort
2. Packaging effort
The second problem is the most pressing. We would have to create packages of just about everything that users would want. Though this would give us a great deal of control over our distribution, it would be a pain in the butt.
Dennis Powell recently mentioned it in his
".comment" article on LinuxPlanet.
Basically, it manages RPMs and source installations (tarballs). The leader of the CheckInstall project is currently working on getting support for Debians ".deb" files.
It would provide a common database for the installation of just about everything that a MaxLinux user would need.
Maybe I should move this discussion to the mailing list. We will probably be working on a solution for package management for a long time. This isn't a bad thing. Package management is important and we need to do it right - The First Time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-04-29
Good points. What would be really cool in a package manager would be automatic dependency retrieval. I've heard talk about this in various places, but nobody seems to have done it. But anyhow, the idea is that there could be a server designated by the MaxLinux team which could hold the latest version of commonly used dependencies. So, when a user installs a program, and they don't have a required dependency, the packaging client could connect to the server, download the needed dependency(s), install them, and continue to install the package as though nothing happened. That would put MaxLinux in a great position on the Linux market.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mandrake have the automatic package dependencies in rpmdrake. It also has source selection and other useful tools.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-04-30
If I understand what you're talking about, Debian (http://www.debian.org) has been doing this for a while with apt-get (a front-end to the Debian dpkg packaging system). If you want to install, say, WindowMaker (which requires popt), you would simply type "apt-get install windowmaker" and it would automatically install both popt and windowmaker (and any other needed dependencies). You can also do "apt-get update;apt-get upgrade" to update all of the packages on your system to the latest version (in the stable branch). This is great for getting security fixes. Furthermore, you can upgrade the entire system to a new version of Debian by changing your the apt sources file and then typing "apt-get dist-upgrade". From my understanding, apt-get has been ported to RPM as well.
The *BSDs sort of have this as well with the ports system, but it involves compiling from source. You simply go to a place in the ports tree and type "make install". It then downloads any needed dependencies and patches needed so that the program works on that particular BSD and then it automatically configures, builds, and installs them. It does take longer than apt-get, though, since it is compiling source rather than just downloading a binary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmmm I agree, rolling our own package manager may be a bit much. It's a bit like re-inventing the wheel.
If we get enough contributors, we could possibly have a "package central" website, like rpmfind.net or linuxmafia.org (Slackware).
If we *do* decide to roll our own, I have the beginnings of a package manager already. It's currently in a state where the important functions (adding, removing, and updating) are in place, but file cleanup needs a little intervention. I'd need to clean up the code documentation a bit before contributing it. It currently only handles precompiled binaries--but adding build-from-source won't be too hard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We should also keep a repository of source tarballs, as well as our own patches to them. I've already got a large repository of stuff I collected to get my own system working. A few of the items are a little out of date though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-04-30
WE can spend more of our time on things that count. And NOT on reinventing the wheel.
RPM and Deb are very well known. And developers know they arn't wasting they time packaging there software in theses formats. if we have your own package type so what!!!!
The only ones that will use our packages are the ones attached to our project. Thats just not right. Use a current standard. WE ARE NOT MIRCOSOFT, WE DON'T REINVENT THE WHEEL AND CLAIM WE THOUGHT IT UP !!!!!
thrawn01@mindspring.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-04-30
Making a new package system wouldn't be reinventing the wheel. The purpose would be making a better wheel (right). But seriously, RPM and DEB have some problems, especially RPM.
If MaxLinux did go with a new packaging system, we would certainly (attempt to) make a package converting system.
There has been some talk about ADR (Automatic Dependency Retrieval) from the folks at Debian, but no work has been done on it that I know of. If anyone wants to know about the idea of ADR, just ask me about it (theshunt@crosswinds.net).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. I need (want) a packager. I have neither the time nor inclination to compile everything I'd like to use.
2. There are times when I do want to compile though, so the packager must be able to handle the fact that I've recompiled something and update itself appropriately.
3. Interoperability with RPM/deb is a must. Again, I don't want to *have to* compile everything. If I find software that will do what I want, I want to install it and run it. Now.
4. Linux Standard Base. 'nuff said.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree. The goals of our package manager needs to be:
1. Able to use RPM and Deb (easy, it is out there)
2. Able to spcify ./configure options and compiler option for the source package. (moderate)
3. Able to detect non package compiled programs. (Now this will likely be hard, quite hard)
4. Dependancy check, auto install (easy to moderate)
5. An easy interface for turning standard (./configure, make, make install) and Perl modules (perl Makefile.pl, make, make test, make install) sources. (Or should we just rely on/use CPAN for that? (moderate to hard)
That, is what I think the major goals should be
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-05-04
For point four, maybe APT would suit the bill. It could be used as one of many components in this package manager, and would fulfill the duties of auto-dependencies. I'm not sure if you can have one version that handles both rpms and debs, but if not, enable it for one of them (debs, for example), and then when the user wants to install a package of a different format, simply use a package conversion program (alien is one, there are some others that come with slackware).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've got an incomplete list of software that we should figure to include with our distribution at http://kelledin.tripod.com/maxlinux/swlist.html
There _will_ be other software added; most of what's there is just what's in my tarball repository, and not even all of that was included.
First, I suggest we record three things about a package: its name, its description, and what steps we took to get it to build.
Second, I suggest that each one of us try to have a "crash box" available for testing the distro. The only major requirements are that it have a 386 or higher CPU, a VGA or better video card, and a fairly large hard drive (6GB should be enough) for loading _all_ the distribution software. This could be yet another boot image on your main box. If the box is a multi-CPU box, you should boot to a single-processor kernel before building packages; some source tarballs will compile differently if they see an SMP kernel. More on this later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, and another thing we should record about each package: where the master copy is maintained.
All this (and the software list) should be moved to Project Documentation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-05-03
Your software list looks pretty good. I just have a few thoughts about it:
- I think that vim should be required, or at least nvi (if space is a concern). vi is the standard text editor on pretty much every *NIX out there, so MaxLinux should follow suit.
- I'd say that teTeX/LaTeX/DVI should be left as optional (if it's included at all). Chances are that most new Linux users won't use it.
Anyway, good suggestions about the package testing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps some office software? If KDE is preferred, probably koffice. What about Gnome / other window managers?
Game libraries (sdl, clanlib etc)?
Should there be palm pilot connection software?
Just some thoughts...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-05-04
I would personally love to see KDE as the default desktop, as well as the center of configuration. But, I do think that GNOME, IceWM, Black Box, FVWM, and any other window managers you guys want should be included. I don't like the idea of a "micro-distribution". If we're going to make a distro, lets give the user alodda software bundled with the distro to chose from.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-05-04
What do you mean by standard text editor?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-05-04
By that, I mean that vi is found universally on all Unix systems (AFAIK). In that way, it's a standard. If there's anything that you could be guaranteed when sitting in front of a Linux, *BSD, Solaris, or AIX system is that you can type in vi <filename> to edit a text file, and all the different versions have the same base features. Emacs, Pico, Joe, Jade, etc. are not a guarantee for all *NIXs.
(BTW: the one exception of a *NIX not having vi is an embeded system, where every KB is precious.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-05-04
Oh, I see, well I think that the standard VI and Emacs should be included. But, I would like to see some other editors included with the distro such as Nano. Nano (for those who don't know of it) is a Pico clone which isn't tethered to an email client. But yes, we should certainly include the antiquated, but standard text editors too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, as for extra window managers...I'd suggest that we have fvwm, gnome, sawfish, and enlightenment in there. mwm and twm are bound to lesstif and to X, but we could package them separately. I don't like gnome myself, but it does have a few apps I rather like. Besides which, many of our packages will depend on gnome libs.
As for office software, the precompiled StarOffice 5.2 is out of the question. That thing crashes if I so much as try to change the font--I think it's an incompatiblity with either X 4.x or with glibc-2.2.1. Man I hate precompiled apps...
Anyways, there's openoffice.org (though I haven't tried it yet). I hear OpenOffice is a memory hog though, just like its closed-source cousin. I haven't tried koffice or abiword either.
Oh, and before anyone catches this, I should change readline to version 4.2. I don't see any reason to build dynamic libs of readline, or to require it. I'm thinking bash is going to be fully static, and I know of nothing else that requires readline. I'm planning on having it as an optional development package (readline-devel-4.2-1).
What DNS server do you all fancy? I'm sure we're all fed up with the security issues with BIND 8/9; one alternative is djbdns. I'd like to just choose one or the other and stick with it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you haven't been added to be part of the project, please email (ce940@hotmail.com) me with your username if you have one, if not signup for one and then send it to me. Also, I am still trying to figure out how to assign tasks to people, once I firgure that out, then you will be assigned tasks.
What do people want to work on, reply to this as a thread.
Michael
Greetings!
I think we should start discussing the whole package management issues.
This is definitely one of the most important issues. It could also make MaxLinux standout in the crowd of distributions.
I'm not sure if we should create our own package manager. It poses two major problems:
1. Development effort
2. Packaging effort
The second problem is the most pressing. We would have to create packages of just about everything that users would want. Though this would give us a great deal of control over our distribution, it would be a pain in the butt.
Why can't we use something like CheckInstall:
http://mayams.net/~izto/checkinstall-en.html
Dennis Powell recently mentioned it in his
".comment" article on LinuxPlanet.
Basically, it manages RPMs and source installations (tarballs). The leader of the CheckInstall project is currently working on getting support for Debians ".deb" files.
It would provide a common database for the installation of just about everything that a MaxLinux user would need.
Maybe I should move this discussion to the mailing list. We will probably be working on a solution for package management for a long time. This isn't a bad thing. Package management is important and we need to do it right - The First Time.
Good points. What would be really cool in a package manager would be automatic dependency retrieval. I've heard talk about this in various places, but nobody seems to have done it. But anyhow, the idea is that there could be a server designated by the MaxLinux team which could hold the latest version of commonly used dependencies. So, when a user installs a program, and they don't have a required dependency, the packaging client could connect to the server, download the needed dependency(s), install them, and continue to install the package as though nothing happened. That would put MaxLinux in a great position on the Linux market.
Mandrake have the automatic package dependencies in rpmdrake. It also has source selection and other useful tools.
If I understand what you're talking about, Debian (http://www.debian.org) has been doing this for a while with apt-get (a front-end to the Debian dpkg packaging system). If you want to install, say, WindowMaker (which requires popt), you would simply type "apt-get install windowmaker" and it would automatically install both popt and windowmaker (and any other needed dependencies). You can also do "apt-get update;apt-get upgrade" to update all of the packages on your system to the latest version (in the stable branch). This is great for getting security fixes. Furthermore, you can upgrade the entire system to a new version of Debian by changing your the apt sources file and then typing "apt-get dist-upgrade". From my understanding, apt-get has been ported to RPM as well.
The *BSDs sort of have this as well with the ports system, but it involves compiling from source. You simply go to a place in the ports tree and type "make install". It then downloads any needed dependencies and patches needed so that the program works on that particular BSD and then it automatically configures, builds, and installs them. It does take longer than apt-get, though, since it is compiling source rather than just downloading a binary.
Hmmm I agree, rolling our own package manager may be a bit much. It's a bit like re-inventing the wheel.
If we get enough contributors, we could possibly have a "package central" website, like rpmfind.net or linuxmafia.org (Slackware).
If we *do* decide to roll our own, I have the beginnings of a package manager already. It's currently in a state where the important functions (adding, removing, and updating) are in place, but file cleanup needs a little intervention. I'd need to clean up the code documentation a bit before contributing it. It currently only handles precompiled binaries--but adding build-from-source won't be too hard.
i would like to be involved in some of the measures taken to enhance desktop usability. both from a new and advanced user perspective.
i can also assist in some of the testing of releases.
I'd like to work on...
1) project documentation (what we user during development) 2) distribution documentation (what we give the user) 3) others..to be determined...
..but spelling may be an issue ( lol )
We should also keep a repository of source tarballs, as well as our own patches to them. I've already got a large repository of stuff I collected to get my own system working. A few of the items are a little out of date though.
WE can spend more of our time on things that count. And NOT on reinventing the wheel.
RPM and Deb are very well known. And developers know they arn't wasting they time packaging there software in theses formats. if we have your own package type so what!!!!
The only ones that will use our packages are the ones attached to our project. Thats just not right. Use a current standard. WE ARE NOT MIRCOSOFT, WE DON'T REINVENT THE WHEEL AND CLAIM WE THOUGHT IT UP !!!!!
thrawn01@mindspring.com
Making a new package system wouldn't be reinventing the wheel. The purpose would be making a better wheel (right). But seriously, RPM and DEB have some problems, especially RPM.
If MaxLinux did go with a new packaging system, we would certainly (attempt to) make a package converting system.
There has been some talk about ADR (Automatic Dependency Retrieval) from the folks at Debian, but no work has been done on it that I know of. If anyone wants to know about the idea of ADR, just ask me about it (theshunt@crosswinds.net).
1. I need (want) a packager. I have neither the time nor inclination to compile everything I'd like to use.
2. There are times when I do want to compile though, so the packager must be able to handle the fact that I've recompiled something and update itself appropriately.
3. Interoperability with RPM/deb is a must. Again, I don't want to *have to* compile everything. If I find software that will do what I want, I want to install it and run it. Now.
4. Linux Standard Base. 'nuff said.
I agree. The goals of our package manager needs to be:
1. Able to use RPM and Deb (easy, it is out there)
2. Able to spcify ./configure options and compiler option for the source package. (moderate)
3. Able to detect non package compiled programs. (Now this will likely be hard, quite hard)
4. Dependancy check, auto install (easy to moderate)
5. An easy interface for turning standard (./configure, make, make install) and Perl modules (perl Makefile.pl, make, make test, make install) sources. (Or should we just rely on/use CPAN for that? (moderate to hard)
That, is what I think the major goals should be
For point four, maybe APT would suit the bill. It could be used as one of many components in this package manager, and would fulfill the duties of auto-dependencies. I'm not sure if you can have one version that handles both rpms and debs, but if not, enable it for one of them (debs, for example), and then when the user wants to install a package of a different format, simply use a package conversion program (alien is one, there are some others that come with slackware).
I've got an incomplete list of software that we should figure to include with our distribution at http://kelledin.tripod.com/maxlinux/swlist.html
There _will_ be other software added; most of what's there is just what's in my tarball repository, and not even all of that was included.
First, I suggest we record three things about a package: its name, its description, and what steps we took to get it to build.
Second, I suggest that each one of us try to have a "crash box" available for testing the distro. The only major requirements are that it have a 386 or higher CPU, a VGA or better video card, and a fairly large hard drive (6GB should be enough) for loading _all_ the distribution software. This could be yet another boot image on your main box. If the box is a multi-CPU box, you should boot to a single-processor kernel before building packages; some source tarballs will compile differently if they see an SMP kernel. More on this later.
Oh, and another thing we should record about each package: where the master copy is maintained.
All this (and the software list) should be moved to Project Documentation.
Your software list looks pretty good. I just have a few thoughts about it:
- I think that vim should be required, or at least nvi (if space is a concern). vi is the standard text editor on pretty much every *NIX out there, so MaxLinux should follow suit.
- I'd say that teTeX/LaTeX/DVI should be left as optional (if it's included at all). Chances are that most new Linux users won't use it.
Anyway, good suggestions about the package testing.
Perhaps some office software? If KDE is preferred, probably koffice. What about Gnome / other window managers?
Game libraries (sdl, clanlib etc)?
Should there be palm pilot connection software?
Just some thoughts...
I would personally love to see KDE as the default desktop, as well as the center of configuration. But, I do think that GNOME, IceWM, Black Box, FVWM, and any other window managers you guys want should be included. I don't like the idea of a "micro-distribution". If we're going to make a distro, lets give the user alodda software bundled with the distro to chose from.
What do you mean by standard text editor?
By that, I mean that vi is found universally on all Unix systems (AFAIK). In that way, it's a standard. If there's anything that you could be guaranteed when sitting in front of a Linux, *BSD, Solaris, or AIX system is that you can type in vi <filename> to edit a text file, and all the different versions have the same base features. Emacs, Pico, Joe, Jade, etc. are not a guarantee for all *NIXs.
(BTW: the one exception of a *NIX not having vi is an embeded system, where every KB is precious.)
Oh, I see, well I think that the standard VI and Emacs should be included. But, I would like to see some other editors included with the distro such as Nano. Nano (for those who don't know of it) is a Pico clone which isn't tethered to an email client. But yes, we should certainly include the antiquated, but standard text editors too.
Ok, as for extra window managers...I'd suggest that we have fvwm, gnome, sawfish, and enlightenment in there. mwm and twm are bound to lesstif and to X, but we could package them separately. I don't like gnome myself, but it does have a few apps I rather like. Besides which, many of our packages will depend on gnome libs.
As for office software, the precompiled StarOffice 5.2 is out of the question. That thing crashes if I so much as try to change the font--I think it's an incompatiblity with either X 4.x or with glibc-2.2.1. Man I hate precompiled apps...
Anyways, there's openoffice.org (though I haven't tried it yet). I hear OpenOffice is a memory hog though, just like its closed-source cousin. I haven't tried koffice or abiword either.
Oh, and before anyone catches this, I should change readline to version 4.2. I don't see any reason to build dynamic libs of readline, or to require it. I'm thinking bash is going to be fully static, and I know of nothing else that requires readline. I'm planning on having it as an optional development package (readline-devel-4.2-1).
What DNS server do you all fancy? I'm sure we're all fed up with the security issues with BIND 8/9; one alternative is djbdns. I'd like to just choose one or the other and stick with it.
Almost forgot, let's include blackbox and windowmaker.
We seem to be accumulating a great many window managers already...