4 ms·

> 2. I want to have more than one version of a package in a distribution. > APT answer: Handwave! You don't need it. You can just have multiple distributions!

> 2. I want to have more than one version of a package in a distribution. > APT answer: Handwave! You don't need it. You can just have multiple distributions! It is because of how we sign things - we sign collections! This is not true at all. If you need to distribute multiple versions of the same package then all you need to do is provide multiple versions of the same package. Just get your act straight, learn how to package software, create your packages so that you can deploy them simultaneously without breaking downstream software, and you're set.

drdaeman 8y ago
AFAIK, dpkg doesn't allow to have multiple versions of the same package installed at the same time. This is not apt's limitation, though.
- UncleEntity 8y ago
  Too lazy to get up from my comfy easy chair to boot my debian running NAS but 99.9% sure there's more than one version of python on that thing.
  - notyourday 8y ago
    No, those are <somepackage>-<someversion> where <somepackage> is different.
    - Conan_Kudo 8y ago
      Correct. Multi-version packages are not supported by dpkg. They are supported by rpm in limited circumstances (no file conflicts allowed!). Fedora and openSUSE kernel packages work this way, as an example. The way Debian works around this is by doing "<name>-<version>" as the package name. This is a valid approach, though it makes package name discovery a bit more difficult at times... As for multiple versions of packages in the repo, "createrepo"/"createrepo_c" (for RPM repositories) does not care. And for Debian, "dpkg-scanpackages" can be made to not care too, using the "--multiversion" switch: https://www.mankier.com/1/dpkg-scanpackages#--multiversion https://www.mankier.com/1/dpkg-scanpackages#--multiversion This is somewhat at your peril, as I've observed APT getting confused when it parses metadata from repositories produced by dpkg-scanpackages that allows multiple versions in the repository. However, reprepro does not support this at all, so most deployments with semi-large Debian repositories will not have this option available to them anyway.
    - geezerjay 8y ago
      > No, those are <somepackage>-<someversion> where <somepackage> is different. It seems there is a significant semantics gap between how deb packages work and what's supposed to be a package version. In deb packages, package versions are lexicograhically ordered descriptions of a version ID that is used to guide autoupgrades. If a packager wishes that multiple minor version releases should be present in a system then he should build his packages to reflect that, which is exactly how Python packages, and specially some libraries, do. For example, python packages are independent at the major version level but GCC packages are independent at the minor version level.
      - notyourday 8y ago
        > If a packager wishes that multiple minor version releases should be present in a system then he should build his packages to reflect that, which is exactly how Python packages, and specially some libraries, do. For example, python packages are independent at the major version level but GCC packages are independent at the minor version level. Not in a system. In a repo. Standard debian tools ( not hacked, not outside the tree, not outside the debian main tree ) do not support this. If you have a repo with <packagename>-<packageversion> and add a package <packagename>-<packageversion1> where packageversion1 is higher than the package version, the previous version gets deleted from the repo. Can it be worked around? Sure, you can: a) have multiple repos. If you want to keep up to a hundred versions, you can just create a hundred repos. b) you can redefine the meaning of a package name and incorporate the version into the name of the package. (b) Sounds like a good solution. Except if the org decided to use something like .deb for distribution of artifacts it is probably the org that uses other software. Let's say it uses puppet, which supports Debian package management out of the box, except that now you need to change how puppet uses version numbers because as we started embedding the version name into the package name "nginx-1.99.22" and "nginx-1.99.23" became two different packages not two different versions of the same package. This goes on and on.
        geezerjay 8y ago
        > Not in a system. In a repo. Standard debian tools ( not hacked, not outside the tree, not outside the debian main tree ) do not support this. That's the semantic gap I've mentioned. Your statement is patently wrong, as deb packages do enable distributions such as Debian and other Debian-based distros such as Ubuntu to provide multiple major, minor, and even point releases through their official repos to be installed and run side-by-side . Take, for example, GCC. Debian provides official deb packages for multiple major and minor release versions of GCC, and they are quite able to coexist in the very same system. All it takes for someone to build deb packages for multiple versions of a software package is to get to know deb, build their packages so that they can coexist, and set their package and version names accordingly.
- notyourday 8y ago
  repropro has that limitation.
- geezerjay 8y ago
  > AFAIK, dpkg doesn't allow to have multiple versions of the same package installed at the same time. That's true, but multiple versions of the same package is not the same as multiple versions of the same software. Debian and Ubuntu have access to multiple minor version releases of GCC and they can all coexist side by side.
notyourday 8y ago
Been there. Done that. It does not work. I want to have nginx-1.99.77 nginx-1.99.78 nginx-1.99.78ehjkhk-1 in the same repo. It is not possible.
- glennpratt 8y ago
  Unless I'm missing something, this is 100% possible. Now, if you want to carefully control the version constraints of these, welcome to pinning hell, but that's a different problem.
  - notyourday 8y ago
    I'm always willing to see how to do it. The repo currently contains <thispackage>-<this-version>-<this-patchlevel>.architecture The package name is <thispackage> I need to add to the repo <thispackage>-<this-version>-<that-patchlevel>.architecture Packages are signed and repo will be signed. At the end I should be able to install the package using the select the specific version flag without adding another repo.
    - deleted 8y ago
      [deleted]
    - glennpratt 8y ago
      This is possible, if you are having issues, it is likely you apt repo tooling, not apt itself. I use aptly and rely on this everyday.
- JdeBP 8y ago
  Rubbish. I have every version of the nosh toolset packages from version 1.22 to 1.39 side by side in a single Debian repository.
  - notyourday 8y ago
    Which tool? https://wiki.debian.org/DebianRepository/Setup#dak_.28Debian_Archive_Kit.29 https://wiki.debian.org/DebianRepository/Setup#dak_.28Debian...

drdaeman 8y ago

AFAIK, dpkg doesn't allow to have multiple versions of the same package installed at the same time. This is not apt's limitation, though.

UncleEntity 8y ago
Too lazy to get up from my comfy easy chair to boot my debian running NAS but 99.9% sure there's more than one version of python on that thing.
- notyourday 8y ago
  No, those are <somepackage>-<someversion> where <somepackage> is different.
  - Conan_Kudo 8y ago
    Correct. Multi-version packages are not supported by dpkg. They are supported by rpm in limited circumstances (no file conflicts allowed!). Fedora and openSUSE kernel packages work this way, as an example. The way Debian works around this is by doing "<name>-<version>" as the package name. This is a valid approach, though it makes package name discovery a bit more difficult at times... As for multiple versions of packages in the repo, "createrepo"/"createrepo_c" (for RPM repositories) does not care. And for Debian, "dpkg-scanpackages" can be made to not care too, using the "--multiversion" switch: https://www.mankier.com/1/dpkg-scanpackages#--multiversion https://www.mankier.com/1/dpkg-scanpackages#--multiversion This is somewhat at your peril, as I've observed APT getting confused when it parses metadata from repositories produced by dpkg-scanpackages that allows multiple versions in the repository. However, reprepro does not support this at all, so most deployments with semi-large Debian repositories will not have this option available to them anyway.
  - geezerjay 8y ago
    > No, those are <somepackage>-<someversion> where <somepackage> is different. It seems there is a significant semantics gap between how deb packages work and what's supposed to be a package version. In deb packages, package versions are lexicograhically ordered descriptions of a version ID that is used to guide autoupgrades. If a packager wishes that multiple minor version releases should be present in a system then he should build his packages to reflect that, which is exactly how Python packages, and specially some libraries, do. For example, python packages are independent at the major version level but GCC packages are independent at the minor version level.
    - notyourday 8y ago
      > If a packager wishes that multiple minor version releases should be present in a system then he should build his packages to reflect that, which is exactly how Python packages, and specially some libraries, do. For example, python packages are independent at the major version level but GCC packages are independent at the minor version level. Not in a system. In a repo. Standard debian tools ( not hacked, not outside the tree, not outside the debian main tree ) do not support this. If you have a repo with <packagename>-<packageversion> and add a package <packagename>-<packageversion1> where packageversion1 is higher than the package version, the previous version gets deleted from the repo. Can it be worked around? Sure, you can: a) have multiple repos. If you want to keep up to a hundred versions, you can just create a hundred repos. b) you can redefine the meaning of a package name and incorporate the version into the name of the package. (b) Sounds like a good solution. Except if the org decided to use something like .deb for distribution of artifacts it is probably the org that uses other software. Let's say it uses puppet, which supports Debian package management out of the box, except that now you need to change how puppet uses version numbers because as we started embedding the version name into the package name "nginx-1.99.22" and "nginx-1.99.23" became two different packages not two different versions of the same package. This goes on and on.
      - geezerjay 8y ago
        > Not in a system. In a repo. Standard debian tools ( not hacked, not outside the tree, not outside the debian main tree ) do not support this. That's the semantic gap I've mentioned. Your statement is patently wrong, as deb packages do enable distributions such as Debian and other Debian-based distros such as Ubuntu to provide multiple major, minor, and even point releases through their official repos to be installed and run side-by-side . Take, for example, GCC. Debian provides official deb packages for multiple major and minor release versions of GCC, and they are quite able to coexist in the very same system. All it takes for someone to build deb packages for multiple versions of a software package is to get to know deb, build their packages so that they can coexist, and set their package and version names accordingly.
notyourday 8y ago
repropro has that limitation.
geezerjay 8y ago
> AFAIK, dpkg doesn't allow to have multiple versions of the same package installed at the same time. That's true, but multiple versions of the same package is not the same as multiple versions of the same software. Debian and Ubuntu have access to multiple minor version releases of GCC and they can all coexist side by side.

notyourday 8y ago

Been there. Done that. It does not work. I want to have nginx-1.99.77 nginx-1.99.78 nginx-1.99.78ehjkhk-1 in the same repo. It is not possible.

glennpratt 8y ago
Unless I'm missing something, this is 100% possible. Now, if you want to carefully control the version constraints of these, welcome to pinning hell, but that's a different problem.
- notyourday 8y ago
  I'm always willing to see how to do it. The repo currently contains <thispackage>-<this-version>-<this-patchlevel>.architecture The package name is <thispackage> I need to add to the repo <thispackage>-<this-version>-<that-patchlevel>.architecture Packages are signed and repo will be signed. At the end I should be able to install the package using the select the specific version flag without adding another repo.
  - deleted 8y ago
    [deleted]
  - glennpratt 8y ago
    This is possible, if you are having issues, it is likely you apt repo tooling, not apt itself. I use aptly and rely on this everyday.
JdeBP 8y ago
Rubbish. I have every version of the nosh toolset packages from version 1.22 to 1.39 side by side in a single Debian repository.
- notyourday 8y ago
  Which tool? https://wiki.debian.org/DebianRepository/Setup#dak_.28Debian_Archive_Kit.29 https://wiki.debian.org/DebianRepository/Setup#dak_.28Debian...