dubuntu-team team mailing list archive

["Jay I." <jay.27182818@xxxxxxxxx>]

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