1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
Debocker is for:
* building deb packages easily
* building deb packages *reproducibly*
1) Build a package magically.
- build a package for the current system
$ debocker build pkg
- build a package for any debian release
$ debocker build -t testing pkg
- build a package for debian release
$ debocker build -t ubuntu/raring pkg
- build a particular version of a packge
$ debocker build pkg=1.23
- build a particular git-tag of a package
$ debocker build-git pkg debian/0.12.4-1
$ debocker build-git http://github.com/thinred/new-package master
This one uses a fact that *some* Debian packages use git to version
control packages. When you give URL, it will check the repo out
at a given tag (master by default) and build it
- build a package from URL
$ debocker build http://www.somewhere.com/package.debr
Notes:
* probably puts the package in a cache or something
* when it's done, it shows the container ID
2) Get a package at a particular version, distribution, etc.
$ debocker get pkg=1.23
$ debocker get-git pkg
Notes:
* does not build, just creates a directory. Maybe initializes
'debocker.conf' in debian/
3) Build current, local package sources
$ debocker build (with no parameters)
$ debocker build --path $path (builds a package at $path)
Notes:
* takes the current state of the repo and builds it in a container
* signs and does all that kind of magic
4) Package a package (sic!) in a reproducible bundle
$ debocker bundle pkg=1.23
$ debocker bundle (for the current directory)
Notes:
* builds the package (to test if it builds at all)
* takes the diff and stores in a compressed file
and information how to build it later;
now, this one is tricky - docker does not allow
this, but there is a feature coming that may kind of solve it:
https://github.com/dotcloud/docker/pull/1974
well, let's keep it for later
* it creates a file like 'bundle.debr' that contains
*all information* to build the package *reproducibly*;
normally, it should not contain the base system (it should
be referenced to some rock solid place)
Additional notes:
* I imagine it could be like that;
one day I do 'debootstrap' to get an initial image; then every
day there is an 'apt-get update' to advance the image; so on the
server there is a chain of images for every day
the developer builds a package using an automatically fetched
yesterday's tag to build on it; then he/she can distribute it
with DEB package, post it somewhere, or something like that
|
