[gentoo-dev] logical extention of /var/db/pkg to /var/db/repos/pkg

[gentoo-dev] logical extention of /var/db/pkg to /var/db/repos/pkg

[Igor]

[-- Attachment #1: Type: text/plain, Size: 4832 bytes --]

Dear All,

I want to share some ideas on conception of /var/db/pkg design and portage.

/var/db/pkg is basically an extended version of a local overlay, it's a database that 
contains all the installed packages and it's data. It could be viewed as an extended 
gentoo overlay but due to possible logical misconception it looks like 
overlay and more than just an overlay but at the same time doesn't have enough information 
to be an overlay. And that problem is the one that I want to focus on and put on your 
consideration. 

The bold suggestion is to propagate /var/db/pkg to a "pkg" overlay that contains all installed 
packages files including distfiles. Therefore /var/db/pkg turns into for example /var/db/repos/pkg special overlay,
which co-exists with ../gentoo and other overlays on equality basis but unlike other 
overlays it contains extended information (files, patches, distfiles and current /var/db/pkg usual data)

* I assume portage --sync is not frozen, the portage is updated the usual

Benefits: 

*  it will be possible in most of the cases to do minimal installs, when you surgically update a required 
   package only - helpful for enterprises (one of the most wanted features over the years BTW)
   (I suggest to add emerge flag --minimal AKA -min AKA -m and a global flag: MINIMAL in make.conf which would 
   imply --minimal for each emerge by default)

*  It will be possible to freeze stable system config. Config freeze is the only option with 
   Gentoo in practical world. You find a stable config, freeze it and then use for years to come 
   and then upgrade it with the new hardware or spend some time for upgrade if it worth it

*  again in the frozen state it will be possible to re-configure the system putting partial not system 
   wide updates during all the frozen stable system service time yet upgrading portage. For example fixing some critical 
   security issues by upgrading packages or re-configuring the use flags.

*  It will open a new chapter in gentoo installation process. Today if we go from
   scratch we have to spend months and months before a stable config found. We upgrade, patch, 
   find bugs and move on and on until we discover a stable configuration which works. That process is 
   tedious and time consuming and the most difficult with gentoo. But if we had a /var/db/pkg overlay
   we would be able to link a profile to a stable /var/db/pkg overlay database and when a user first installs 
   gentoo he or she will be able to choose between the usual pre-atomic profiles and the profiles linked to a stable pre-set 
   /var/db/pkg (local stable overlay proven and configured by gentoo). I bet the majority will choose not to mess with 
   the atomic profiles - I wouldn't. If a stable profile with pre-set 
   config is chosen then gentoo pulls in with the profile a stable /var/db/pkg database and compile and merge
   all the packages from the pulled /var/db/pkg. That will produce a stable system ready-to use (about 3 months of work 
   saved at least)

*  A new feature could be introduced to the portage : profile update with /var/db/pkg : users wouldn't have to mess with 
   the packages on atomic level but will update one stable system on another stable globally making huge steps. 
   Today when disc space or wideband is not a problem - sure it is possible to build for example desktop systems with 
   wide range of applications pre-installed and then bundle the updates to the /var/db/pkg database. 

*  a maintainer(s) will manage /var/db/pkg stable snapshots for desktop / sever applications just like the common packages

*  in almost all of the cases it will be possible to re-compile the system to it's current state with all the packages 
   currently installed without any Internet connection or distfiles current availability 
   
It does look like a hybrid - taking benefits of a binary distro and merging it with a source based distro 

I can see only one problem (which implies a wrong design?) eclass EAPI backward compatibility. But even without that 
compatibility that would be a logical thing to do with /var/db which is and always was a representative of an
overlay of installed packages for Gentoo but was not treated by emerge like that

If EAPI were backward-compatible the system could be maintained indefinitely but even with the present backward-compatiblity 
a local database would maintain full-rebuild capability for at least 4 years and partial for many many years

Anyway when more experience received something could be done with /var/db/pkg/eclass which could differ from /var/db/gentoo/eclass 
in a way they would support more EAPIs 

Thanks for reading that long. 

-- 
Best regards,
 Igor                          mailto:lanthruster@gmail.com 

[-- Attachment #2: Type: text/html, Size: 6134 bytes --]