dubuntu-team team mailing list archive

[Ryan Macnish <nisshh@xxxxxxxxxxx>]

Yea i figured as much but we may as well create the branch in our bzr repo for the frontend? That way i have somewhere i can show you guys how i intend to build the frontend.

Subject: Re: [Dubuntu-team] cli frontend
From: charl.wentzel@xxxxxxxxxxxxxx
To: nisshh@xxxxxxxxxxx
CC: jay.27182818@xxxxxxxxx; dubuntu-team@xxxxxxxxxxxxxxxxxxx
Date: Tue, 7 Jul 2009 14:15:23 +0200






  
  


Hi Ryan



Not yet.  Once we've completed this thread I think we'll have a better idea.  We first need to clear up our "philosophy"/approach.  It will determine what needs to go into the front-end.



Regards

Charl



On Tue, 2009-07-07 at 10:41 +0930, Ryan Macnish wrote:


    Ahhhh ok im just going to reread that a few times so that i can fully understand it but so far so good.

    

    also sorry if one of you guys doesnt get a few of my posts, i keep accidentally hitting reply instead of reply to all.

    

    Anyone have any ideas as to what they want the GUI frontend to include?

    

    > From: jay.27182818@xxxxxxxxx

    > To: dubuntu-team@xxxxxxxxxxxxxxxxxxx

    > Date: Mon, 6 Jul 2009 19:22:01 +0300

    > Subject: Re: [Dubuntu-team] cli frontend

    > 

    > i've changed names of some commands and added a couple of new ones:

    > 

    > $ ./dpm help

    > dpm should be invoked using this format:

    > 

    > dpm <command> [<arguments>]

    > 

    > where <command> is one of the following:

    > 

    > help - view short description of dpm usage,

    > open - open a package category,

    > close - close a previously open package category,

    > list - output a list of items inside a package category,

    > add - add a category or package to local database,

    > delete - remove a category or package from local database,

    > read - show description of a category or package,

    > write - update description of a category or package,

    > install - install a category or package,

    > uninstall - uninstall a category or package,

    > include - include a repository,

    > exclude - exclude a repository,

    > sources - list repositories included into local database.

    > 

    > you can type 'gpm help <command>' to view description of a specific

    > command.

    > $

    > 

    > i'm gonna stick up with this list and won't add any new commands until i

    > finish these ones.

    > 

    > and here is a high level overview of the entire model of our package(or

    > environment?) management system.

    > 

    > database:

    > 

    > every devbuntu installation will have its own database and will be quite

    > autonomous. it will be also possible to synchronize a local database

    > with our central database through a webservice.

    > 

    > each package added to a database will come from some repository and

    > prior to adding a package description to the database user will need to

    > add a corresponding repository (in form of APT line). all repos from the

    > database will be dumped to /etc/apt/sources.list and apt will be used to

    > handle them.

    > 

    > after adding a repo user will be able to add all packages from that repo

    > to his local database. packages that we will add to our central database

    > will be scattered all over the internet and most of the time we'll be

    > picking just a couple of them from a repo. i think it won't be always

    > right to add all required packages for a given one. lets imagine that

    > some newbie wants to install a compiler that requires a dozen of

    > packages with ugly names and cryptic descriptions that are used only by

    > this compiler. i ask myself - where would i place such packages? if i

    > place them in the same category with the compiler then when the newbie

    > will be browsing that category he will face all that hell of names and

    > terms he knows nothing about so there are two ways to place such

    > packages - into a separate category or just nowhere. by following the

    > first way we will end up with lots of categories with names similar to

    > <packages_requires_by_a_package> or we will have one or several large

    > categories full of such packages. i think it's more wise to put only the

    > most important packages into our database and let apt handle additional

    > dependencies. this approach will save us time, will be more convenient

    > for newbies and for pros we'll be just displaying entire lists of

    > packages prepared by apt for installation.

    > 

    > i also think that providing package descriptions only in one language is

    > not a good idea so i included a special table that will hold localized

    > versions of package titles and descriptions. every package will have

    > three textual properties: english name (e.g. xterm), title (e.g. 'X

    > terminal emulator') and description. the backend library will allow

    > front ends to switch between supported languages and will fetch data

    > from the local database only in the currently selected language.

    > 

    > installation/uninstallation:

    > 

    > actual package management will be performed by dpkg. the backend will

    > use apt-get to generate uris of packages to be fetched but will perform

    > downloading itself. this will allow us to reuse existing tools and gain

    > control over downloading process.

    > 

    > this is how a typical installation will be perfromed: a front end will

    > supply the backend with a path to a package or package category (yes, we

    > will allow users to install entire categories), the backend will fetch

    > all relevant records, convert them to apt-get arguments and invoke

    > apt-get with --print-uris option, then it will download the package(s),

    > put them into /var/cache/apt/archives/ (maybe. not sure about it yet)

    > and invoke dpkg to perform actual installtion.

    > 

    > i ask you to post your comments and questions because it's much easier

    > to change anything at this stage. if everything is acceptable i will

    > post entire db dump along with detailed explanation of every field and

    > table. then i'll commit my code to the repo.

    > 

    > 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

    

    



    Click Here View photos of singles in your area
_______________________________________________
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


_________________________________________________________________
Get the latest news, goss and sport Make ninemsn your homepage!
http://windowslive.ninemsn.com.au/article.aspx?id=813730