dubuntu-team team mailing list archive

[Ryan Macnish <nisshh@xxxxxxxxxxx>]

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

_________________________________________________________________
View photos of singles in your area Click Here
http://dating.ninemsn.com.au/search/search.aspx?exec=go&tp=q&gc=2&tr=1&lage=18&uage=55&cl=14&sl=0&dist=50&po=1&do=2&trackingid=1046138&r2s=1&_t=773166090&_r=WLM_EndText