dubuntu-team team mailing list archive

[Ryan Macnish <nisshh@xxxxxxxxxxx>]

Oh i forgot, Charl is there a specific reason why you made them +junk instead of trunk. What we really should have is a separate project page for development and this team can be listed as the owners and drivers. Otherwise it can get confusing about where our code is and where our bugs and blueprints are supposed to be.

From: nisshh@xxxxxxxxxxx
To: charl.wentzel@xxxxxxxxxxxxxx
Date: Thu, 9 Jul 2009 12:41:10 +0930
CC: dubuntu-team@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Dubuntu-team] cli frontend








Excellent, im going to upload a simple example GUI with instructions in a text file. That way you will get an idea of how gnome GUI's work.

> Subject: RE: [Dubuntu-team] cli frontend
> From: charl.wentzel@xxxxxxxxxxxxxx
> To: nisshh@xxxxxxxxxxx
> CC: jay.27182818@xxxxxxxxx; dubuntu-team@xxxxxxxxxxxxxxxxxxx
> Date: Wed, 8 Jul 2009 21:44:20 +0200
> 
> Hi guys
> 
> I created 2 bazaar repos..
> 
> a. For the API Library 
> lp:~dubuntu-team/+junk/environment_manager_api
> 
> b. For the Gnome front-end
> lp:~dubuntu-team/+junk/environment_manager_gnome
> 
> Let me know if they work for you... or if I need to create more.
> 
> Regards
> Charl
> 
> On Wed, 2009-07-08 at 19:58 +0930, Ryan Macnish wrote:
> > 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
> > 
> > 
> > ______________________________________________________________________
> > Make ninemsn your homepage! Get the latest news, goss and sport
> 

Click here to find out more POP access for Hotmail is here!
_________________________________________________________________
Get the latest news, goss and sport Make ninemsn your homepage!
http://windowslive.ninemsn.com.au/article.aspx?id=813730