Hi,
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
records).
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
possible.
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
Regards,
--
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