dubuntu-team team mailing list archive

[jay <jay.27182818@xxxxxxxxx>]

hi charl

here's my vision of the question. it's based on your proposal so i'll
just mention what's different and what you didn't explain. i'm also a
bit busy today so here's a very short explanation of my ideas.

1). what will it all look like?
first of all we have a very nice installer in ubuntu 8.10 (it's gui
based and quite simple). so i suggest to split installation in two main
steps. first you make a very basic installation of ubuntu (just a few
core packages, desktop and some utilities like gedit) with a slightly
modified default ubuntu 8.10 installer. this will provide you with a
clean up-to-date installation that you will be able to use in any way
you want not necessarily transforming it into a development environment
(maybe you will only want to play with core system utilities to gain
some knowledge in this field). then you boot into ubuntu and manually
(or automatically) run package selector.

2). Package selector. I suggest another name for this tool - software
configuration manager (scm for short). it will replace both synaptic and
software sources manager and will provide a higher level of abstraction.
it will manage current software configuration on localhost (and maybe on
remote machines as well). software configuration consists of
megapackages, metapackages, package catergories and sofware packages.

megapackage (what you call subdistro) is a set of metapackages combined
together to provide an environment suitable for a number of tightly
related activities. examples of megapackages:

- core (a set of core packages; see 1).).
- development studio
- multimedia center (listen to music, watch video etc.)
- multimedia studio (the same but with approp. editing tools)
- gaming center
- home server (web server, mail server, database server etc.)
- office workstation

each metapackage describes a certain activity (when a megapackage
describes a set of related activities). examples of metapackages inside
'development studio' megapackage:

- cli development
- gui development
- web development
- software packaging
- documenting (editors for man pages, etc. maybe even ooo.writer)

every metapackage will contain a number of package categories. here's an
example for 'cli develpment' metapackage:

- compilers
- ide's
- debuggers
- documentation
- ... maybe something else.

every metapackage, package category and package must have a good
description so that a newbie developer will not have any questions
regarding which c++ compiler to install, what ide to use with it, etc.
for example when selecting kdevelop a user will know from the comment
that it can be used with gcc. and when selecting say g++ he/she will
know that it's a c++ precompiler that's used with gcc. maybe we'll have
a special meta field that will describe which compiler which language
supports. and the order in which categories appear is important as well
- first you are likely to select a compiler and only then an ide.
management process can be implemented as a step-by-step procedure,
that's similar to your idea of questions.

so scm will provide a comfortable way for both newbies and pros to
easily manage their software configuration. i've got some idea of what
gui i will provide but i have no time to describe it here.

with scm users will be able to install, update, create and share
software mega/metapackages, package categories and packages(not sure
about creation but it'd be great to have such a feature). our web site
will provide both a web interface for humans and a webservice for scm
and other utilities.

i should mention another important thing: you suggest to have a
configuration management feature inside the installer but i think we
should keep things as simple as possible. if we add such functionality
to the installer we will make it very complex and complicate development
and debugging. giving user an ability to edit configuration both while
installing the system and after it will give an extra choice that he/she
obviously doesn't need. newbies will feel themselves much more
comfortable when configuring the system after it's successfully
installed than while installing it as making even some very basic
installation is a great stress for a newbie. also imagine this
situation: a user has made his choice about what to install but then he
decided to put it off and just make a clean installation. when this
happens during installation there's no possibility to store the choice
somewhere as there may be no filesystem on the hard drive because the
installer first asks where and what to install and only then creates a
filesystem and make other changes to the system. also if something goes
wrong it's much easier to fix errors related to system core
functionality when you first make a clean install and have an ability to
test installation at this point. also if we develop scm as a normal app
intended to run in some graphical environment it will be much easier to
test it and maybe even port it to another platform.

3). database. the database will have several tables:

- packages. it will contain a description for every package, e.g. name,
version, description, rating, repository. having these metadata scm will
be able to install packages from multiple repos without requiring user
to do add them manually via software sources manager.

- package categories
- metapackages
- megapackages.

4). i suggest using c++ instead of python. first of all almost every
linux developer knows it or at least is able to understand sources. if
we use c++ we'll be able to receive contributions from a much bigger
community of developers and we'll make our work understandable for the
rest of world. you know that most of software we may use throughout our
development process is written in c/c++ so we won't need any special
bindings to use it and if we decide to adopt some third-party code
there's a great chance that we'll have fewer problems with it.

5). release schedule. should we follow debian/ubuntu one or just provide
regular snapshots (some of them will correspond to ubuntu releases)? i
think the latter variant is more suitable 'cas you won't have to
download several hundreds of megabytes of updates when you try to
install devbuntu in the middle of the period between current and next
releases.

best regards,
jay


On Tue, 2008-12-09 at 07:32 +0200, Charl Wentzel wrote:
> Hi guys
> 
> I wanted to create a full descriptive document of the installer, but
> find myself a little short of time.  So here's a short version.
> 
> The concept of the installer is already well laid out in the wiki, so
> please read that first.  In this mail I'll focus on the conceptual
> inner workings of the installer:
> 
> Background:
> 
> First of all note that the aim is not to create a separate
> distribution like Kubuntu or Xubuntu, but rather an add-on
> installation, more in the line with Edubuntu.  Developers quickly
> understand and customise their Linux to suite themselves, so I don't
> wish to upset their already customised environment, but we do want to
> enhance it.  The installer is therefor less of a Ubuntu-installer and
> more of a "very advanced" package selector.
> 
> Another important point is that we do not want to reinvent the wheel
> and redo that which has already been done.  We would like to use as
> much of the existing framework and utilities that already exist.  This
> is the reason for it being a package installer.  Once you've installed
> it something like Adept takes over and constantly upgrades the package
> for you (or with your permission, whichever way you've configured it).
> 
> So we're left with two problem:
> - Simplifying and enhancing package selection and installation
>     This is where the installer comes in, which is described below
> - Knowing what to install
>     This is where the webstie comes in.  We don't know everything but
> there a community out there that would like to share... I hope.
> 
> Operation:
> 
> The package selector must have a bunch of questions it will ask you.
> The first level of these questions should be result based, i.e. "what
> do you want to do?".  This should have questions like:
> - Which programming language(s) do you prefer (C++, Pacal, Java,
> Python, perl, etc)
> - What type of applications do you want to develop (command line,
> kernel, Gnome, KDE, etc)
> 
> The next layer will show you a high level selection of tools (without
> too much details, based on the answers.  This could be something like:
> - IDE: KDevelop, Ajunta, etc
> - Compilers: Gnu gcc
> - Libraries: libstdc, etc
> - Tools: ValGrind, Cachegrind, etc
> - Documentation: ....
> - etc
> 
> Under each heading there will be list of options.  From here you can
> then select the specifics of what you want (or everything if you
> like). 
> 
> Inner workings:
> 
> To make the selection I suggest we use an "really big" XML file.
> Actually, I would prefer an embedded database due to the amount of
> information we will have and the speed at which we need to process
> it.  
> 
> Firstly, In this definition will be all the questions that needs to be
> asked with all the possible answers for each question.
> 
> Secondly, we will have a list of all the "package sets" you need.  For
> each set we will have the answers to the questions that is required to
> add this package set to the first level selection.  If we have a
> database, this selection can be done with a few queries.
> 
> This will be compiled from the data on the website, refer to the
> "columns" I've suggestions.  The website will contain all the
> suggestions with comments.  We can mark these suggestions as approved
> and export it directly to the installer when we release it.
> 
> Development:
> 
> It's been suggested that we use Python with GTK for the front-end.  In
> the back-end we can use apt and MySQL (both of these have interface
> libraries for Python and will drastically reduce the work).
> 
> Apt will do the interfacing to the repo libraries.  MySQL can easily
> be embedded into an applications so you don't actually have to install
> MySQL server or clients to use the database.
> 
> If we do the website with MySQL as well, it saves having directories
> with files.
> 
> Vision:
> 
> There are two more things worth mentioning here:
> 
> - Customised selections
> We could allow you to "save" your final selection to a file, which you
> can share (hopefully on our website). These files could then be loaded
> as short-cuts so you don't have to answer all the questions or refine
> the selection again. This would allow for the following:
> a. Setting up several of your machines in exactly the same way... VERY
> QUICKLY
> b. Allow Ubuntu projects to define there development environments and
> get newbies going... VERY QUICKLY
> c. Share your "revelation" of what a development environment should
> look like with your friends.  The same way we share our videos on
> YouTube and our thoughts on blogs
> 
> These short-cuts can be saved as XML instead.
> 
> - Other projects
> A good package installer like this would actually open up a whole new
> world of possibilities for guys wanting to create add-on distributions
> like Devbuntu and Edubuntu.  They could use this installer to create
> there own "sub-distros" for other things, e.g. graphics design, making
> music, making movies, etc.  Think of the possibilities.  What we are
> doing here, or rather the way we plan to do it, is not limited just to
> development enviroments.
> 
> So what do you think?
> 
> Charl
> 
> 
> 
> -----Original Message-----
> From: jay <jay.27182818@xxxxxxxxx>
> To: Charl Wentzel <charl.wentzel@xxxxxxxxxxxxxx>
> Subject: package selector for devbuntu
> Date: Sun, 07 Dec 2008 18:51:25 +0200
> 
> hi charl. i'd like to ask you a couple of questions about your idea of
> package selector - what will it actually be? what will be the format for
> files it will produce? i can suggest this scheme but i'm unsure is it
> similar to what's on your mind or not:
> 
> 1). on some host we will have a directory with files which names
> correspond to development categories (gui, commandline, web etc.). each
> of these files will contain a list of packages that will be installed
> when user makes appropriate choice during installation process or
> post-installation tweaking.
> 
> 2). we'll have a pool for proposals on the same host - a separate
> directory with patches for appropriate files in the main directory or
> new files for new dev. categories.
> 
> 3). we'll have a web interface (a simple form or so) to approve
> proposals and some other administrative tasks. the host will also
> provide a web-service that can be used to create commandline utilities
> or gui frontends.
> 
> i didn't send this message to the list 'caz i just want to figure out
> what you mean when saying 'package selector' before sending any
> proposals to the list.
> 
> best regards,
> jay
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dubuntu-team
> Post to     : dubuntu-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dubuntu-team
> More help   : https://help.launchpad.net/ListHelp