1 |
Dear All, |
2 |
|
3 |
I want to share some ideas on conception of /var/db/pkg design and portage. |
4 |
|
5 |
/var/db/pkg is basically an extended version of a local overlay, it's a database that |
6 |
contains all the installed packages and it's data. It could be viewed as an extended |
7 |
gentoo overlay but due to possible logical misconception it looks like |
8 |
overlay and more than just an overlay but at the same time doesn't have enough information |
9 |
to be an overlay. And that problem is the one that I want to focus on and put on your |
10 |
consideration. |
11 |
|
12 |
The bold suggestion is to propagate /var/db/pkg to a "pkg" overlay that contains all installed |
13 |
packages files including distfiles. Therefore /var/db/pkg turns into for example /var/db/repos/pkg special overlay, |
14 |
which co-exists with ../gentoo and other overlays on equality basis but unlike other |
15 |
overlays it contains extended information (files, patches, distfiles and current /var/db/pkg usual data) |
16 |
|
17 |
* I assume portage --sync is not frozen, the portage is updated the usual |
18 |
|
19 |
Benefits: |
20 |
|
21 |
* it will be possible in most of the cases to do minimal installs, when you surgically update a required |
22 |
package only - helpful for enterprises (one of the most wanted features over the years BTW) |
23 |
(I suggest to add emerge flag --minimal AKA -min AKA -m and a global flag: MINIMAL in make.conf which would |
24 |
imply --minimal for each emerge by default) |
25 |
|
26 |
* It will be possible to freeze stable system config. Config freeze is the only option with |
27 |
Gentoo in practical world. You find a stable config, freeze it and then use for years to come |
28 |
and then upgrade it with the new hardware or spend some time for upgrade if it worth it |
29 |
|
30 |
* again in the frozen state it will be possible to re-configure the system putting partial not system |
31 |
wide updates during all the frozen stable system service time yet upgrading portage. For example fixing some critical |
32 |
security issues by upgrading packages or re-configuring the use flags. |
33 |
|
34 |
* It will open a new chapter in gentoo installation process. Today if we go from |
35 |
scratch we have to spend months and months before a stable config found. We upgrade, patch, |
36 |
find bugs and move on and on until we discover a stable configuration which works. That process is |
37 |
tedious and time consuming and the most difficult with gentoo. But if we had a /var/db/pkg overlay |
38 |
we would be able to link a profile to a stable /var/db/pkg overlay database and when a user first installs |
39 |
gentoo he or she will be able to choose between the usual pre-atomic profiles and the profiles linked to a stable pre-set |
40 |
/var/db/pkg (local stable overlay proven and configured by gentoo). I bet the majority will choose not to mess with |
41 |
the atomic profiles - I wouldn't. If a stable profile with pre-set |
42 |
config is chosen then gentoo pulls in with the profile a stable /var/db/pkg database and compile and merge |
43 |
all the packages from the pulled /var/db/pkg. That will produce a stable system ready-to use (about 3 months of work |
44 |
saved at least) |
45 |
|
46 |
* A new feature could be introduced to the portage : profile update with /var/db/pkg : users wouldn't have to mess with |
47 |
the packages on atomic level but will update one stable system on another stable globally making huge steps. |
48 |
Today when disc space or wideband is not a problem - sure it is possible to build for example desktop systems with |
49 |
wide range of applications pre-installed and then bundle the updates to the /var/db/pkg database. |
50 |
|
51 |
* a maintainer(s) will manage /var/db/pkg stable snapshots for desktop / sever applications just like the common packages |
52 |
|
53 |
* in almost all of the cases it will be possible to re-compile the system to it's current state with all the packages |
54 |
currently installed without any Internet connection or distfiles current availability |
55 |
|
56 |
It does look like a hybrid - taking benefits of a binary distro and merging it with a source based distro |
57 |
|
58 |
I can see only one problem (which implies a wrong design?) eclass EAPI backward compatibility. But even without that |
59 |
compatibility that would be a logical thing to do with /var/db which is and always was a representative of an |
60 |
overlay of installed packages for Gentoo but was not treated by emerge like that |
61 |
|
62 |
If EAPI were backward-compatible the system could be maintained indefinitely but even with the present backward-compatiblity |
63 |
a local database would maintain full-rebuild capability for at least 4 years and partial for many many years |
64 |
|
65 |
Anyway when more experience received something could be done with /var/db/pkg/eclass which could differ from /var/db/gentoo/eclass |
66 |
in a way they would support more EAPIs |
67 |
|
68 |
Thanks for reading that long. |
69 |
|
70 |
-- |
71 |
Best regards, |
72 |
Igor mailto:lanthruster@×××××.com |