Discussion of ProxMox package tree structure

SuSt

Well-Known Member
Dec 11, 2009
61
1
48
Moscow, Russia
When I was updating/upgrading my servers, I found some strange (from my point of view) features of ProxMox repository dependency tree. For example, I can't realize why is it necessary:
1. To build an "own" proptietary PVE kernel, when Deabian contains its OpenVZ kernel, which is robust enough.
2. To name proxmox repo "lenny". I suppose, it should be much more convenient to name it something like "lenny-pve" in order not to mix with the according Debian release.
3. To provide "own" proprietary pve-firmware package, when Debian has multiple ones, e.g. firmware-bnx2 which contain the same drivers.
4. To produce a "proxmox-ve-xxx" package which is dependent from kernel, when the package "pve-manager" exists. I suppose, an experienced user can choose all theese himself. Or, it is possible to create a package with "variant" (optional) dependencies.

Et cetera...

I should like to discuss theese questions with community. Your ideas?
 
When I was updating/upgrading my servers, I found some strange (from my point of view) features of ProxMox repository dependency tree. For example, I can't realize why is it necessary:
1. To build an "own" proptietary PVE kernel, when Deabian contains its OpenVZ kernel, which is robust enough.

we maintain several kernel branches with specific features. see http://pve.proxmox.com/wiki/Proxmox_VE_Kernel

2. To name proxmox repo "lenny". I suppose, it should be much more convenient to name it something like "lenny-pve" in order not to mix with the according Debian release.
I see no need for this. the line for sources list is pointing to lenny, so why do you think this is misleading?
(# PVE packages provided by proxmox.com
deb http://download.proxmox.com/debian lenny pve)

3. To provide "own" proprietary pve-firmware package, when Debian has multiple ones, e.g. firmware-bnx2 which contain the same drivers.
No, this is not true. Debian Etch and Lenny (and lets see how it is going with Squeeze) did not provide these firmware packages. Therefore we put much efforts in this (with success). And not all our Kernels are based on Debian Kernels.

4. To produce a "proxmox-ve-xxx" package which is dependent from kernel, when the package "pve-manager" exists. I suppose, an experienced user can choose all theese himself. Or, it is possible to create a package with "variant" (optional) dependencies.

Et cetera...

I should like to discuss theese questions with community. Your ideas?

thats the intention of virtual package. easy and convenient installation. why don´t you like this?
 
1. I could not notice any "specific features" that are present in ProxMox proprietary kernel and simultaneously absent in native Debian kernel. I am ready to beleive that such differences exist, but I could not found them.

2. OK, I'll explain. For example, you have two repositories, linked to your system: pve and "native" debian lenny. The package "vzctl" can be found in both repos. I want to install one (and the right one!) of them. How can I do it? If ProxMox repo had a different name, I would issue a command like "apt-get -t lenny-pve install vzctl". But the repos are named equally!

3. Sorry, I couldn't understand. Theese packages can be found in debian repos, in "non-free" section. What is the problem to link and install them?

4. Because if someone wants to get rid of "proprietary" PVE kernel (e.g. to install "native" debian kernel), he is forced to uninstall "proxmox-ve-*" too. And then packet manager offers to remove all other components of ProxMox VE as well. But such behaviour is not what the one wants. I mean that I should like to possess a bit more flexible installation, allowing to change some components to theirs analogs (e.g. kernel) and to update/upgrade my system safely.
 
1. I could not notice any "specific features" that are present in ProxMox proprietary kernel and simultaneously absent in native Debian kernel. I am ready to beleive that such differences exist, but I could not found them.

There are many differences, but this will will blow up this thread. Just think of our stable OpenVZ Kernel branch which is based on RHEL5.

2. OK, I'll explain. For example, you have two repositories, linked to your system: pve and "native" debian lenny. The package "vzctl" can be found in both repos. I want to install one (and the right one!) of them. How can I do it? If ProxMox repo had a different name, I would issue a command like "apt-get -t lenny-pve install vzctl". But the repos are named equally!

For Proxmox VE you need our package and this is installed automatically via the virtual package. you never should use the Lenny version. We never provide a package if the default one is working like we need it - as this would make no sense.

3. Sorry, I couldn't understand. Theese packages can be found in debian repos, in "non-free" section. What is the problem to link and install them?

No, not all and not in the time we needed them.

4. Because if someone wants to get rid of "proprietary" PVE kernel (e.g. to install "native" debian kernel), he is forced to uninstall "proxmox-ve-*" too. And then packet manager offers to remove all other components of ProxMox VE as well. But such behaviour is not what the one wants. I mean that I should like to possess a bit more flexible installation, allowing to change some components to theirs analogs (e.g. kernel) and to update/upgrade my system safely.

Seems you do not understand the concept of the Proxmox VE. Its a defined distribution optimized for virtualization. Its not just a Kernel or a GUI, its a package. If you do not want this, just go for Debian or any other distribution. If you use Proxmox VE you can get support here from a very helpful and fast growing community and also commercial support subscriptions from us.

BTW, what is a proprietary kernel? All our packages are GPL.
 
1. OK, no more questions.

2. You are right, except one moment. Try to imagine what will happen during next system upgrade (dist-upgrade). For example, when someone would like to upgrade from ProxMox 1.7 (based on Lenny) to ProxMox 2.0 (based on Squeeze). As another example, you can look at official "Lenny-backports" or "Squeeze backports" repositories. They are not just another sections, but they are named different themselves.

3. OK, but there is another thing to keep in mind. Sometimes in some situations ProxMox packages can conflict with Debian packages because of same contents and dependencies. It's not a very pleasant situation. "pve-firmware" is among them.

4. Ok, your concept is your undoubtful right. I can't dispute it. But in my humble opinion, first of all ProxMox VE is just a very convenient Web-GUI for OpenVZ, not less, not more. I agree, ambitions is a very good thing, but I used to be realistic. Nothing personal. It's just my point of view. May be, someone else will confirm or refute it.

BTW. I know that it is GPL, so I everywhere write the word "proprietary" inside quotation marks.
 
1. OK, no more questions.

2. You are right, except one moment. Try to imagine what will happen during next system upgrade (dist-upgrade). For example, when someone would like to upgrade from ProxMox 1.7 (based on Lenny) to ProxMox 2.0 (based on Squeeze). As another example, you can look at official "Lenny-backports" or "Squeeze backports" repositories. They are not just another sections, but they are named different themselves.

we provide an easy upgrade script from Proxmox VE 1.x to 2.x. Like we did it from Etch to Lenny.

3. OK, but there is another thing to keep in mind. Sometimes in some situations ProxMox packages can conflict with Debian packages because of same contents and dependencies. It's not a very pleasant situation. "pve-firmware" is among them.

we make sure that this does not happen. if you got issues like this, post it. I see no problem with pve-firmware. only if you do something unsupported, like a dist-upgrade to squeeze.

4. Ok, your concept is your undoubtful right. I can't dispute it. But in my humble opinion, first of all ProxMox VE is just a very convenient Web-GUI for OpenVZ, not less, not more. I agree, ambitions is a very good thing, but I used to be realistic. Nothing personal. It's just my point of view. May be, someone else will confirm or refute it.

BTW. I know that it is GPL, so I everywhere write the word "proprietary" inside quotation marks.

You are wrong if you think Proxmox VE is just a GUI for OpenVZ. its a special distribution for Open Source virtualization with a great community.
 
first of all ProxMox VE is just a very convenient Web-GUI for OpenVZ, not less, not more. I agree, ambitions is a very good thing, but I used to be realistic. Nothing personal. It's just my point of view. May be, someone else will confirm or refute it.

Well, I guess the GUI is about 5% of the work we do.