Peter Michaux wrote: > I'm thinking particularly of a personal/company repository where > packages cannot be tested as well as they are in Debian before they > are declared "stable" and sent to production servers. It is more > likely for a company that a undetected problem makes it to production > and the first person to notice is a customer. How does the company > react in such a case so that customers are happy?
Thanks for that clarification. In that context: > > If the new version can be fixed? Is a fixed version added with a > > higher number? After fixing a problem make and release and upload to your repository a new package with a later version number. It will then be available to anyone that has that repository in their sources.list file. I can't stress this point enough. When making a new version always use a later version number. Do not try to release a changed version but with the same version number as before. No one will think it looks bad to have multiple versions released fixing bugs. On the contrary people will view that as being an alive, active project that with support. (And yet I routinely run into people trying to release multiple version of the same version. I once saw a project try to release four versions with quick hot fixes all as the same version number. They were embarrased that it was needed and tried to hide it by continuing to use the same version number. That just creates additional problems. Don't do it. Publish each version number once only.) > > What if the new version cannot be fixed? Is the new version of the > > package simply removed? Is an even newer version added that actually > > matches the previous working version until bad one can be fixed and > > added again? Package systems used with GNU/Linux systems such as dpkg and rpm have so far avoided the entire concept of patches. Some other systems release incremental changes and therefore require keeping a lot of system information in order to upgrade or downgrade. To avoid that problem dpkg and rpm both package the entire thing. They have 100% of everything needed in one version. Perhaps with multiple packages that work together but all across one version of them. When preparing a fixed package the new package is a full package completely replacing the previous version of the package. When we upload a fixed version of the package the previous version may be forgotten about. (Although Debian keeps them archived as they are useful for many other reasons.) Let me show an example use case. Living in Debian Unstable means having both Unstable and Testing in the sources.list file. If something is broken in Unstable I can manually select the version from Testing and downgrade. In general downgrades are not supported (config files or state files may not be forward compatible) but when debugging a specific package I can know if downgrading will work or not. (If not I can always purge and then re-install pristine the previous version and that is supported.) If you were to release a buggy package version and I installed it and realized that it was buggy I would manually select the previous version and downgrade to it as part of the debugging. This is made easier if you keep not only the newest version around but also keep a previous known good version around too. If you don't then I as a downstream user would need to do so myself. That is a pain. Other users might not be savvy enough to do this for themselves. Therefore I recommend you helping them out by keeping a previous known good version easily available for installation too. Removing a package from a repository does not remove it from a user's system. Removing a package from a repository simply means it is no longer available from that repository to install. (Package files will undoubtedly still exist elsewhere such as /var/cache/apt/archives though.) If it is necessary to take some emergency action such as pushing out an upgrade that "defuses a bomb" as Henrique mentioned then it is possible to create an empty or denatured package. The package manage will upgrade from the old package to the new package. Since the bad contents of the old package are removed and replaced with the new this could be used to "safe" a bad package release. I also do not recall this ever being needed with Debian packages. One place to be extra careful about such things is in the package installation scripts and the prerm and postrm scripts specifically. Don't make any hazardous mistakes there. Otherwise someone that simply removes the package will trip over problems in those scripts. I do recall rare times when bugs existed there and hacks were needed in the later package in order to take corrective action in those scripts. Possible to save. But ugly. Best is not to need them. Package scripts is one area where dpkg is clearly superior to rpm. The script order for rpm packages is in an unfortunate bad order. With rpm a buggy package script may not be safely upgraded. With dpkg the script order is better, I will dare say correct, and that design flaw of rpm script order is avoided. Note that uploading a newer package that is empty does not force a downstream user to upgrade and prevent them from using your software. I doubt that is what you are asking about but I will head that off preemptively. It is not a technique for removing something from a non-compliant customer's system. Nothing forces them to upgrade. And if they did they could always install a previous saved off version of the package. Bob
signature.asc
Description: Digital signature
