1 |
solar <solar@g.o> wrote on 2011/12/25 18:52:52: |
2 |
> |
3 |
> On Sun, 2011-12-25 at 11:34 +0200, Kfir Lavi wrote: |
4 |
> > |
5 |
> > |
6 |
> > On Fri, Dec 23, 2011 at 3:23 PM, Joakim Tjernlund |
7 |
> > <joakim.tjernlund@×××××××××.se> wrote: |
8 |
> > |
9 |
> > I got the impression from docs that PKG_INSTALL_MASK would |
10 |
> > actually |
11 |
> > mask files out so they never get into the binary package, this |
12 |
> > doesn't |
13 |
> > seem to happen. |
14 |
> > Did I misunderstand? If I did, I think an MASK to do the above |
15 |
> > would be a worthy addition to quickpkg, very useful for |
16 |
> > embedded targets to keep the pkg size down. |
17 |
> > Also PKG_INSTALL_KEEP which would list files keep(rest is |
18 |
> > dropped) would be nice. |
19 |
> > |
20 |
> > Oh, something else I wonder about. How does pre/post install |
21 |
> > work with |
22 |
> > quickpkgs? Is it possible to have such scripts and then have |
23 |
> > qmerge execute |
24 |
> > them? |
25 |
> > |
26 |
> > Jocke |
27 |
> > |
28 |
> > |
29 |
> > Yes, PKG_INSTALL_MASK on time of installation will mask the files |
30 |
> > defined in it. |
31 |
> > Binary package do contain all files, even the masked files. |
32 |
> > Kfir |
33 |
> |
34 |
> |
35 |
> $PKG_INSTALL_MASK is supposed to omit the files in it's list from making |
36 |
> it into the binary pkgs in the first place. The idea there was to make |
37 |
> smaller binary pkgs for embedded devices and such (for use only with |
38 |
> private repos). |
39 |
> |
40 |
> $INSTALL_MASK is supposed to omit the files listed in it from being |
41 |
> installed on the file system. |
42 |
|
43 |
Hi Solar, long time no see :) |
44 |
|
45 |
So the current behaviour is a bug, good to know. |
46 |
|
47 |
I am contemplating a greater problem too. Our system require we can install |
48 |
multiple versions of our SW and switch between them. This is easy to do when it |
49 |
comes to our own app but not when one want to upgrade core parts of the system, like |
50 |
libc etc. |
51 |
|
52 |
So I am thinking one could use --bind mounts and switch_root to solve that. Basically |
53 |
one has a skeleton root FS with /bin, /lib, /usr /opt etc. |
54 |
Each upgrade goes into dirs like: |
55 |
bin_1.x.y/ usr_1.x.y/ lib_1.x.y/ opt_1.x.y/ sbin_1.x.y/ |
56 |
Then, from an initramfs, one selects which of xxx_1.x.y dir one wants to use |
57 |
and --bind mounts them under the corresponding skeleton dir. |
58 |
|
59 |
To do that one needs an way to repackage a root fs created by a bunch of different |
60 |
ebuilds, some of them spanning several of the above dirs, into a package per xx_1.x.y dir. |
61 |
Not sure if this can be done with the current portage/portage-utils and how, any |
62 |
ideas welcome :) |
63 |
|
64 |
Perhaps there is a better way then the above? |
65 |
|
66 |
Jocke |