[Devel] vzpkg

[Robert Nelson]

Kir Kolyshkin wrote:
>
> Also see my comments below.
>
> Robert Nelson wrote:
>> Is anyone actively working on vzpkg?
>>
>> I've been rewriting it to eliminate the dependence on yum and rpm, so 
>> that it also works for Debian and hopefully some day Gentoo.  This 
>> also eliminates the requirement for vzyum, vzrpm, vzrpm43 and 
>> vzrpm44.  vzpkgadd, vzpkgrm, vzpkgls and vzpkgcache would just do the 
>> right thing.  This would also fix the incompatibilities between 
>> working with packages from the HN and from within the VE.
>
> That sounds interesting, do you have a git repo or something I can 
> take a look at?
>

I haven't got a repo set up but I could set one up pretty easily.

> So, how are you solving the problem of different RPMDB versions? You 
> know, if you have used rpm-4.2 to create/manage an RPM database, the 
> moment you use rpm-4.3 on it will become incompatible with rpm-4.2. 
> The only way to fix that would be to use only specified RPM version.
>
> We can definitely use rpm from inside a VE only, but then another 
> problem of duplicate downloads arises.
>

This problem was pretty easy to solve once I figured out what was going 
on.  I just remove the __db.* files before and after running commands in 
the HN then RPM automatically rebuilds them on the next command.

For the yum-cache, I mount the /vz/template version of the cache into 
the VE.  I do the same for the apt/archives on Debian.

>> Is this something that you would like to incorporate into the product?
>>
>> One of the things I noticed was that there was a lot of duplication 
>> in scripts and data files.  This is because everything is stored in 
>> an OS/Version/Platform/Config directory, even though there may not be 
>> any difference between the corresponding files between platforms or 
>> even Versions.
>>
>> I have a change which is backwards-compatible which allows config 
>> directories anywhere in the template tree.  Files lower in the tree 
>> override any specified higher in the tree.
>>
>> For example, instead of this directory structure:
>>
>>    /vz/template
>>       centos
>>          4
>>             i386
>>                config
>>                    minimal.list
>>                    yum.conf
>>                    ...
>>             x86_64
>>                config
>>                    minimal.list
>>                    yum.conf
>>                    ...
>>
>> You would have:
>>
>>    /vz/template
>>       centos
>>          config
>>             minimal.list
>>          4
>>             i386
>>                config
>>                   yum.conf
>>                   ...
>>
>> This eliminates a lot of duplicate work and is less error prone.
> Will the minimal.conf in 
> /vz/template/centos/5/i386/config/minimal.list be an addition to, or a 
> replacement for /vz/template/centos/config/minimal.list?
>
Currently it is a replacement, in all the templates I looked at the 
files were exactly the same.  The *.list files just list the desired 
functionality which doesn't change, the big changes are the dependencies 
which are handled automatically.  But they definitely don't differ 
between architectures for the same release.

I handle things a little differently for Debian / Ubuntu since 
debootstrap files provide the initial set.  Packages listed in the 
*.list file are added to a --include option to debootstrap, if they have 
a trailing - then they are added to --exclude.
> In case it's addition, say you have a package called httpd in 
> /vz/template/centos/config/minimal.list. What if in CentOS 6 we don't 
> want package with that name, but want something called httpd3 instead? 
> I mean, we can definitely add more packages, but how can we "remove" 
> packages?
>
> In case it's a replacement, I doubt that "generic" file will work -- 
> every major version of a given distro have some changes in the 
> minimal.list.
>>
>> I can provide a diff of this change against the current git if you 
>> are interested.
>>
>> If there is interest in any of this work please let me know the 
>> process for getting the changes reviewed and incorporated into the 
>> product.
>
> I put users@ to cc: in order to bring some more attention to the 
> topic. I am definitely interested so let's discuss it further (for now 
> my biggest concern is rpmdb compatibility problem described above).