Dňa Wed, 06 Apr 2011 15:05:10 +0200 Luca Saiu
<Luca.Saiu@xxxxxxxxxxxxxxxxxxxx> napísal:
I have put everything I made about debian/ubuntu packages for
marionnet in http://www-lipn.univ-paris13.fr/~butelle/marionnet
Great, thanks Franck. Jean-Vincent, let's give a good look at that,
too.
I take look on it and it look as it was hard work. I am using debhelper
to save my work and then my rules files for both ocamlbricks and
marionnet-kernels packages are very simple:
- ------- Start rules 2 -------------
%:
dh $@
- ------- End rules 1 --------------
And only for marionnet package is a bit complex:
- ------- Start rules 2 -------------
%:
dh $@
override_dh_auto_build:
dh_auto_build
make documentation-all
override_dh_auto_clean:
dh_auto_clean
rm -f share/marionnet.conf
- ------- End rules 2 --------------
first override is for documentation generation and second one removes
mentioned file (missing in make clean?)
By this, all job is moved to Makefile and all packaging job is moved
to debhelper helper files (for example install and docs, more here
http://www.debian.org/doc/manuals/maint-guide/dother.en.html). By this,
if any changes happen, it is enough change only one file (Makefile) to
get all pieces to work together.
I am not so proud about all this stuff, but "it works"(tm).
I do not use pbuilder but directly dpkg-buildpackage.
No idea about any of this :-).
i am using debuild, which makes the same work. Difference is only one,
because the debuild first runs dpkg-buildpackage for package building,
but after this it runs lintian to check some package quality and rules.
Lintian reports some warning, but it is no problem now.
For one architecture and one debian version is pbuilder not needed. But
it is useful to build packages for different architectures (i386 &
amd64 for me) and for different versions (stable, testing) too. By
pbuilder it is possible to build packages for ubuntu too, but i never
try it. And all these packages can be builded in one machine, with one
operating system installed.
Then decision is simple, if we want to distribute packages for more
archs and/or more distributions, the pbuilder is needed. If is enough
to build only one package version, pbuilder is not needed.
pbuilder provides pdebuild command, to build packages in it, and
understands some environment variables and has a lot command line
options, to allow invoking it from cron to build different things, for
example weekly/daily svn snapshots. And finally, pbuilder gives
mechanism to update/upgrade your own chroots, to follow current state
of debian.
I can help with setting the pbuilder, but perhaps there will be more
experiments needed to get it works as expected - because i was playing
with this some time ago and maybe i forgot some things now.
I think we also need a (simple) script for /etc/init.rc/ to start
marionnet.daemon.
dont't wory about script. I take script from old package (mentioned in
copyright), removed some bashism and did some improvement in
start-stop-daemon invocation and it works now for me (i am often writing
"for me", while i know that what is working for me, not must to be
working for others).
The packages produced by the scripts have been tested for ubuntu.
My packages are builded only for debian testing now and are not
installable for stable - unmet dependencies (versions).
Next step: propose the packages to debian officials repositories !
IMHO, first will be good idea to put these things to git (or what is
used for versioning). I can extract debian directories from all
packages and to send them to Luca (or to whom?) as tar.gz. After this
can testing starts :-)
Simplest way can be, if i will have write access to them, but i work
only with svn yet. This allow me test all changes localy and upload
only working versions :-) (see below)
We have two problems: one is building the kernel from sources rather
than from binaries (not a big deal, we can (and should) do it). The
second problem is building filesystems. Having binary images of
filesystems is not exactly something clean, which debian would
accept... We should really understand and use Geppetto (Slavko:
Geppetto is the system for buildign Pinocchio filesystems, written by
Jonathan Roudiere; right now he's the only one who understands it);
when I saw him some weeks ago Jonathan told me it's essentially ok,
and that he just needs one or two weekends to polish it.
Geppetto allows to generate filesystem images at "compile time",
from sources. That's clean and powerful, and I think much more
acceptable than an ugly, 200Mb binary file.
First - i know nothing about UML, but i have one idea, please consider
this:
My packages install all marionnet files under /usr tree (and nod
under /usr/local), to follow debian policy and Linux FSH. By this
regular users cannot install custom kernels nad filesystems, only
administrators.
If marionnet will be searched kernels and filesystems not only in
system tree, but in user's home too (perhaps ~/.marionnet/kernels,
etc), this will allow to all users download custom kernels and FS, or
use custom compiled one, without administrator's privileges needed. This
will need some GUI changes, to add download menu options and code for
downloading and verification.
Then plan can be to provide Geppetto (and Pinocchio - nice :-) ) as
package, for use on local machines to build FS.
I have idea to not distribute kernels nad FS as packages, but create
way to (optional) download in package reconfigure time, which happens
while installation/upgrade too - by maintainer scripts. By this we can
avoid duplication these files - once for direct download and second in
packages...
What is your opinion, please?
Anyway, I think official blessing from debian would be nice but is not
strictly a priority.
when we will have proper packages, we can fill bug with new package
request and then we can supply our packages to debian directory and get
support with this. But i never try this :-)
- --
s pozdravom
Slavko
http://slavino.sk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk2cfrgACgkQ/eUL2Y7rwi34kwCeMGNJ3q6dXeI45HCQhYMqMOHz
4lEAoIIjrHOlJVKR7mzcLC9oX22Ugfd5
=4I7I
-----END PGP SIGNATURE-----
!DSPAM:105,4d9c8a8637011882820818!
