Downgraded by apt-get from 10 to 9

upgrade

#1

Hi,

I ran apt-get update and was downgraded from 10.0.3 to 9.1.

I am guessing this happened because it was originally installed using the Ubuntu repo and then updated using a .tar.

I have a couple of questions.

  1. If I remove owncloud.list is that all I need to do to ensure that apt-get does not update owncloud?
  2. If I add the stable release owncloud.list will I be able to upgrade from 10.0.3 to 10.0.10?

And some questions about the process:

  1. If downgrading is not supported why would the update not check to see if the installed version is newer or not? Can I add a check somewhere or is there an App that does this?
  2. Which is actually the preferred installation method? The tar or the repository?

#2

As system owner, you alone are responsible what you allow apt or any other package manager to do.

I think it’s a matter of personal taste. I would NEVER install ownCloud from an linux repo. So my answer is clearly tarball, what else. :wink:


#3

I don’t think I’ve ever heard of an application that rolls back with update. It is extremely unconventional, and counter-intuitive. Moreover, it’s unsupported so why would it be possible without at least confirmation and/or limited to occ. In fact, version.php seems to restrict upgrade paths and occ checks version when run.


#4

If you install from repo and then nail a tarball over it, who can expect this to work. IMHO you cannot blame ownCloud for this.


#5

Hey,

i fully agree with @alfredb

I think every software available in the world which gets initially installed via the package manager and then gets updated manually behaves exactly the same if the package manager decides to install an older version like happen in your case.

To my knowledge the package manager is the “master”, no software can prevent that it gets overwritten by the package manger to a version the package manager thinks he need to install.


#6

Don’t really care about blame. Not a big deal to restore.

It does seem like a bug to me or at least a feature that would be useful.

I note that there is an unhandled exception logged in term.log:

An unhandled exception has been thrown:
OC\HintException: [0]: Downgrading is not supported and is likely to cause unpredictable issues (from 10.0.3.3 to 9.1.8.2) ()

While apt-get might overwrite manual patches, is it normal to continue an install when there is an exception?

Version.php lists the build number, and occ seemingly checks that, apt-get logs the error, the webapp also shoots up a warning. So, clearly there is a way for owncloud to prevent it.


#7

Hey,

it seems ownCloud has already prevented it (see your posted message) so its seems to me that its now up to you to decide in which direction to go (manual tarball installation, repository installation).

After restoring the latest 10.0.10 code i would say “lessons learned” for the future.:grinning: I had to learn the same years ago where i thought it might be a good idea (for some now unknown reasons) to install gcc over the existing gcc version of the package manager. :confused:

But generally i don’t think that an application like ownCloud can prevent every case where users are shooting themselves into the foot by e.g. switching installation methods from one to another.

I don’t think that apt-get has any knowledge about the status of ownCloud. From what i know the “owncloud-files” archive is just extracted at one place (/var/www/owncloud) and nothing more.


#8

That sounds like no fun.

Apt-get doesn’t of course. But you can have both pre-installation scripts and interactions in .deb packages so far as I know. At least some packages check for previous configuration files and prompt the user to continue using those or the new ones. Doesn’t seem outlandish to me, since the check is done, just in a post-installation script it looks like.

I fully agree, that moving from repo to tar should not require any such checks, of course. But I can’t imagine a use case for downgrading without the user explicitly forcing it since downgrading is unsupported.


#9

Also, looking more closely at my apt logs. This is new behavior.

I installed from tar last November, and since then I have done updates at least quarterly.


#10

Hey,

thanks for this insights. I must admit that i’m not that familiar with apt-get besides the common “install/uninstall” packages.

But to me the handling of something like preventing downgrades within the packages additionally to whats already included in ownCloud itself (downgrade preventing) sounds to me like doubled work and complexity and additional logic which might break something else or similar.


#11

But owncloud doesn’t prevent the downgrade. It just warns you about it and let’s it happen.


#12

Hey,

please correct me if i’m wrong but how should a software ever be able prevent something like this? if its get overwritten by older files (either manually or via apt-get) the only thing it can do is to warn the user (which is the case as it seems) or stop completely. :confused:

And if additionally counter-measures are implemented in the packages, which seems to be not the recommended deployment method anyway according to the documentation:

For production environments, we recommend installing from the tar archive.

then the users of the recommended deployment variant are left out. :confused:

But if you think ownCloud should behave differently / in some other way maybe you can share your expectations with the ownCloud development team? From what i know that team is reachable via https://github.com/owncloud/core/issues


#13

Pre.install scripts are to be added by the package maintainer - so please depending on the repo from where you got the packages contact the package maintainer.

For our own let me summon @crrodriguez @jnweiger


#14

I got it from the install guide, I am sure.

But I still find it curious is that I have run apt-get numerous times and never been downgraded. Not sure if I got 10.0.3 from tar since it is mentioned in the install guide to change the version number. I’m just guessing because the tar is on the server.