0

I repacked a proprietary program delivered as tar file to a deb file for having a company wide repository.

I used reprepro to set up a repository and signed it. A unix timestamp is faking a versioning numbering, so I can have different (real) versions installed at the same time. Almost everything works as expected. The deb file looks like this: mysoft8.0v6_1366455181_amd64.deb

Only problem on a client machine it tries to install the same deb file over and over again because it thinks its an update. What do I miss:

control file in deb package looks like this:

Package: mysoft8.0v6
Version: 1366455181
Section: base
Priority: optional
Architecture: amd64
Installed-Size: 1272572 
Depends:
Maintainer: me
Description: mysoft 8.0v6 dpkg repackaging

and the config in the repository: /mirror/mycompany.inc/conf/distributions:

Origin: apt.mycompany.inc
Label: apt repository
Codename: precise
Architectures: amd64 i386
Components: main
Description: Mycompany debian/ubuntu package repo
SignWith: yes
Pull: precise

Help much appreciated

Added guide: This Is the guide I used to create the repository.

Johannes
  • 333
  • A client side solution can be found here: http://askubuntu.com/questions/18654/how-to-prevent-updating-of-a-specific-package. – Jeffery Williams Oct 25 '13 at 12:34
  • Ty for your input Jeffrey. I want to avoid configuring anything on the client for several reasons. We have a lot of workstations and if I have to configure a workaround for everyone I might as well skip the whole concept of a centralized software repository where I can push automatic updates to the users and install several versions in parallel. So this is not a real solution. On top I don't want to use a workaround for ill-configured servers. I must have made a mistake repacking the files and/or implementing the repository. – Johannes Oct 25 '13 at 15:19
  • Using 'unix timestamp' may be the problem. Try a non-changing number – Prinz Oct 27 '13 at 09:24
  • Prinz - The timestamp in the name is there for a fake versioning - since timestamp naturally always grow. This is done because I need to install several versions of the same software in parallel like this /opt/vendor/mysoft1 and /opt/vendor/mysoft2. If I repack I just create a new timestamp and I have a "newer" version without interfering with the real newer versions. But this is done in the packing process. Maybe the problem is not clear: The same package with the same name and version wants to update itself. I just mentioned the packing process, but I think it's a repository problem. – Johannes Oct 28 '13 at 16:13
  • Would you be willing to post the lines from dpkg.log (/var/log/dpkg.log) that show the package being installed? Maybe it will give someone a clue. – Jeffery Williams Oct 29 '13 at 07:34

1 Answers1

0

To have different versions of the software installed at the same time, you need to use different package names rather than different version numbers; only one version of a package (identified by name) can be installed at the same time.

For example, let's say you need to have MySoft 7 and MySoft 8 installed at the same time, but also need to upgrade each version when the vendor releases minor updates. Maybe you start with MySoft 7.0 v6 which you want installed in /opt/vendor/mysoft7 and MySoft 8.0 v2 which you want installed in /opt/vendor/mysoft8 then you would build two packages:

Package: mysoft7
Version: 7.0.6

and

Package: mysoft8
Version: 8.0.2

to create mysoft7_7.0.6_amd64.deb and mysoft8_8.0.2_amd64.deb. In theory you can use whatever version scheme you want, but it would be advisable to conform to Debian conventions when specifying the version number.

Then, if you need to upgrade either version due to upstream changes from the vendor, then you would build a new version of the relevant package and update the relevant version number. For example, if MySoft 8.0 v3 is released, you would now build:

Package: mysoft8
Version: 8.0.3

Installing this package would then automatically uninstall mysoft8 version 8.0.2 thereby removing the files installed from mysoft8_8.0.2_amd64.deb and replacing them with the files contained in mysoft8_8.0.3_amd64.deb

If you need every single upstream version installed at the same time, then you would need to use a different package name for every version. At this point, the package version number becomes irrelevant and you can just use 1.0. Each would need to install to a different directory, because a file can only be owned by one package at a time. In this scenario, you would have to clean up unwanted old versions of the software manually by uninstalling the relevant package.

I am slightly unclear on why your current deb would try to reinstall if it is already installed (which, unfortunately, is the crux of your question!). It suggests that apt thinks that the version of the package available in your repo is higher than the version installed. Perhaps the size of the version number is confusing it? /var/log/dpkg.log and /var/log/apt/history.log should show you what is going on.

  • Hi David, thank you for your sorrow explanation. I believe I packed my packages as you described it. mysoft7.0v6 and mysoft7.0v7 etc ...

    The pseudo versioning is added to the normal versioning so my packages look like this: mysoft7.0v6_1366455181 and mysoft7.0v7_1366XXXXX etc...

    Here is my history.log: Start-Date: 2013-10-30 11:08:34 Commandline: apt-get upgrade. Upgrade: mysoft7.0v6:amd64 (1366455181, 1366455181) End-Date: 2013-10-30 11:08:53

    – Johannes Oct 30 '13 at 10:21
  • Very odd. As an experiment, I would try rebuilding the package with a fixed, small version number instead of the timestamp. Then manually install on a client, wipe the old package from your repo completely (reprepro remove precise mysoft7.0v6?), import the new package into the repo and try apt-get update && apt-get upgrade again. – David Edwards Oct 30 '13 at 10:23
  • oops. sorrow = thorough :D. I'm not a native English speaker sorry. I think I will start all over as you have suggested. – Johannes Oct 30 '13 at 10:33
  • used simple version numbering and update problem stops. Thank you. – Johannes Dec 11 '13 at 19:28