[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

debimg development restarted


I have just restarted the development of debimg, with a completely
new codebase which will hopefully lead to debimg 0.1.

At the moment, it is not able to create images, but the dependency
resolver, fetcher, and compression tools already exist.

debimg 0.1 uses the low-level apt_pkg and apt_inst bindings, because
debimg does not need the functionality provided by apt.* modules.

It is planned that debimg 0.1 uses a YAML configuration file, with
support for including other files (so you can seperate package lists
and main configuration).

You will be able to build all images in a single run, whereas multiple
types of images (cd,dvd,bd) are built almost in parallel, eg. dependency
resolution only once.

I also have some questions:

Q0. What do you think about the current codebase of debimg? Do you like
    it, understand it?

Q1. The images ship install.ARCH directories. What is the correct naming
    for these directories?

Q2. In advance to question 1, does debimg needs to patch the bootloader
    configuration for these directory names? If yes, wouldn't it be
    possible to patch the files before they are put on the mirrors?

Q3. How can I find out which kernels should be included on the image?
    There is no common naming scheme, it seems. Some have version
    appended, some not, etc.

Q4. I want to ship a finished (no RC-bugs, full functionality) debimg in
    Squeeze (before the freeze). If I can reach this goal, when do you
    think should Debian move to debimg for official images?

And information:

I1. debimg's dependency resolver works the way that no package on a disk
    N depends on a package on disk N+1. 

I2. debimg may not work in cases where a two package (AA,AB) have a cyclic
    dependency and package AA depends on a package X, which depends on AB,
    because this is converted to ((X,), (AA, AB)). The correct way would
    be ((AA, AB, X)) [all on the same disk]. This only affects a very small
    group of packages.

I3. debimg will be able to estimate the size of the image more precisely,
    including most information (Packages.gz, etc.).

I4. debimg is not able to rollback additions to an image, because we can't
    seek backwards in the compressed file [Packages.gz,etc]. (They are written
    on package additions, so we can return the memory occupied by package

I5. debimg uses external programs only where no other solution is possible.
    This means that the only external program call should be genisoimage.

I6. Once I have completed the python-libisofs bindings, debimg will use
    them for ISO-only images. genisoimage will be used for the others.

I7. debimg.core can be used for other stuff as well, especially the
    compression module. Modules are independent of each other, where

Please CC me on responses, as I'm not subscribed to debian-cd anymore.

Vcs-Browser: http://git.debian.org/?p=users/jak/debimg.git
Vcs-Git: git://git.debian.org/users/jak/debimg.git

Julian Andres Klode  - Free Software Developer
   Debian Developer  - Contributing Member of SPI
   Ubuntu Member     - Fellow of FSFE

Website: http://jak-linux.org/   XMPP: juliank@jabber.org
Debian:  http://www.debian.org/  SPI:  http://www.spi-inc.org/
Ubuntu:  http://www.ubuntu.com/  FSFE: http://www.fsfe.org/

Attachment: signature.asc
Description: Digital signature

Reply to: