dubuntu-team team mailing list archive

[Charl Wentzel <charl.wentzel@xxxxxxxxxxxxxx>]

Agreed!  I just wanted to raise the issue so we know about it in the
future.  When you do the development you can allow for it.

Charl

On Tue, 2009-07-07 at 02:06 +0300, Jay I. wrote:
> hi charl
> 
> i think it's too early to talk about .rpm and other distros. first of
> all we need to achieve some success inside ubuntu community and maybe it
> will be enough. maybe we will decide to concentrate on something more
> important. who knows?
> 
> on the other hand, every package, be it a .deb file or a tarball, comes
> from a repo, be it a debian repo or just a regular directory on your web
> server. for every package in db i specify an index into the table which
> contains all included repos. debian repos are currently added in form of
> APT lines. but we can extend this format to something like:
> 
> <deb|rpm|tar> <src|bin> <uri>
> 
> and the backend library will decide what a particular tool to use to
> install a certain package. i think it's quite simple so for now we can
> safely forget about all other formats and concentrate on debian
> packages.
> 
> jay
> 
> On Mon, 2009-07-06 at 21:59 +0200, Charl Wentzel wrote:
> > Hi Jay
> > 
> > Some more thoughts on the existing tools.  Both you and Ryan have
> > mentioned other operating systems / distros.  If we're going to keep an
> > open mind on this we'll need to consider the following:
> > 
> > 1. Embedded server
> > This would definitely be the way to go, since you would then not be
> > dependent on the specific shared library versions installed with a
> > specific distro, you simply compile everything you need into the API
> > library.
> > 
> > 2. .dep, .rpm, ....
> > Apt would only be applicable to debian based distros.  What if the
> > distro uses rpms or even worse requires a source compile?
> > 
> > To cater for this we'll need to use the CLI interface of whatever
> > package installer is used by the distro.  So instead of just specifying
> > the package name in the database, we'll need to define the repositry/ftp
> > site (if necessary) as well as the standard CLI API for installing
> > packages.
> > 
> > E.g. for ubuntu it would be: "apt-get install [package name]".  For a
> > basic distro you may need to first specify a small script that would do
> > a ftp download, configure, make, make install, etc...  I don't know how
> > its done with rpms.
> > 
> You'll have to specify this in the etc/devbuntu files, as you'd have a
> > separate knowledge base and installer definition for each distro.
> > 
> > On your gui you would then do the same thing as Synaptic.  Once you've
> > made youre selection you run the installer in an embedded terminal
> > window so you can see what's happening.
> > 
> > Just a thought!  If you want to keep an open mind, you should do it
> > right from the start!
> > 
> > Charl
> > 
> > On Mon, 2009-07-06 at 19:55 +0300, Jay I. wrote:
> > > hi.
> > > 1. agree about languages.
> > > 
> > > 2. see my posts in 'cli front end' thread. we will reuse as many
> > > existing tools as possible.
> > > 
> > > 3. mysql client won't be used to access our central database because its
> > > just more secure to make it accessible only to serverside scripts and
> > > not to the rest of the world. i'm currently developing cli client that
> > > works with mysql server on localhost. it wont be hard to update it to
> > > use embedded server afterwards.
> > > 
> > > 4. i think all the 'questions' can be mapped to package categories. and
> > > the package manager will just guide user through their hierarchy, asking
> > > questions based on category names and description. user will start at
> > > the root and step down to a leaf - this is equivalent to asking
> > > question.
> > > 
> > > what about xml definition - they can be generated from database records
> > > automatically and it's a better choice to keep everything in a database
> > > and extract data for exchange/sharing.
> > > 
> > > 5. is our bzr repo prepared? i've already designed the backend api (the
> > > most basic function) and i'd like to show you my code. i think we need
> > > separate branches for the backend/fontends.
> > > 
> > > 6. anyway we will must provide a cli based frontend - it'll be just a
> > > shame not to;). as i already mentioned all the questions can be mapped
> > > to package categories and it's technically possible to guide a user
> > > through a tree like hierarchy.
> > > 
> > > 7. agree on qtk+ and qt. i've described my vision of the back end of our
> > > system in 'cli front end'.
> > > 
> > > regards,
> > > jay
> > > 
> > > On Mon, 2009-07-06 at 10:38 +0200, Charl Wentzel wrote:
> > > > Hi Guys
> > > > 
> > > > I think it would be a good idea if we created a quick thread to through
> > > > around a few ideas on the system design and functionality before I
> > > > update the wiki.
> > > > 
> > > > 1. Language
> > > > Both Python and C++ were suggested for the development of the installer;
> > > > Python for its spead of development, C++ since it is the core on which
> > > > Linux was build and the language most people know.  They are both great
> > > > and I don't mind either.  So I guess its up to you guys to decide.
> > > > 
> > > > 2. Apt
> > > > Since we'll be installing packages it makes sense using the tools that
> > > > are already available.  The best one for us would be apt (apt-get and
> > > > related tools).  Once you've worked your way through the questions and
> > > > selected the options you want apt will do the actual installing of
> > > > packages.  
> > > > 
> > > > And of course both Python and C++ have API's/libraries for apt, so
> > > > building an app with apt integrated into it is also possible.
> > > > 
> > > > 3. Database
> > > > The knowledge base must be stored in a database.  There were some
> > > > discussions on the use of a database.  MySQL was suggested.  It also
> > > > allows you to build the database directly into the application rather
> > > > than using a db server or client.
> > > > 
> > > > This will require carefull consideration.  We might want to access both
> > > > the database on the Devbuntu site and(/or) a local copy.  The server
> > > > installation will cover both, but will also require the database server
> > > > to run on the local machine.  Suggestions?  Maybe MySQL client to access
> > > > the web server and integrated client libraries to access the local copy?
> > > > 
> > > > 4. Application Definition
> > > > XML was suggested for storing the questions, categories, etc. which
> > > > defines how the installer would work.  This is a cool idea as this would
> > > > allow each application for the installer (eg. development, multimedia,
> > > > education, etc) to have its own operation/identity.  In fact an upgrade
> > > > for the installer might actually just be an update of the application
> > > > definition and not the executables
> > > > 
> > > > Of course MySQL could also be used to store this info, but if you want
> > > > to store information about the database to use, it will have to be in a
> > > > file.  On the other hand, XML is much easier to manipulate by manually
> > > > if you want to develop (or play with) the installer.
> > > > 
> > > > 5. DevBuntu API
> > > > Most of the above will have to be packaged in a library on which we can
> > > > build the different interfaces... and of course to allow the creative
> > > > comuity out there to create there own front-ends.  This library/API will
> > > > probably take a lot of effort to design.
> > > > 
> > > > We'll need to consider all the operations/functions we wish to perform
> > > > and allow for flexible commands to do it with.  This might actaully be
> > > > done parallel with designing a gui as the gui will give you a great idea
> > > > of what you need.
> > > > 
> > > > 6. CLI
> > > > We've spoken about using the CLI to support legacy, but after thinking
> > > > about it, it might not be so practical.  How do you guide someone
> > > > through questions and selections on the command line and still have
> > > > something that is user-friendly.  If you must ncurses seems to be the
> > > > better route if you have to go text.
> > > > 
> > > > 7. GUI
> > > > The most obvious starting point would be GTK+ as this covers the "main
> > > > stream" Ubuntu.  A Qt version can also be done for the Kubuntu guys,
> > > > etc...  as long as they both use the same DevBuntu API.
> > > > 
> > > > So this is the structure the way I see it:
> > > > 
> > > >    |------Possible Front-ends-------|
> > > >    NCurses      GTK+       Qt   .....
> > > >        \         |         /
> > > >         \        |        /
> > > >         DevBuntu API/Library
> > > >         /        |        \
> > > >        /         |         \
> > > >  KnowlegeBase   Apt     App Def File
> > > >    (MySQL)   (apt-get)      (XML)
> > > >  |-------Tools/dependencies--------|
> > > > 
> > > > 
> > > > Does this work for you?  Would love to hear your comments.
> > > > 
> > > > Charl
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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
> > > 
> > 
>