Find the answer to your Linux question:
Results 1 to 3 of 3
Hi all I'm building a certain RPM package that must require an old version of that same package in order to be installed/upgraded. Is this possible? For example: For a ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Dec 2006
    Posts
    5

    Question RPM: package requires old version of same package - possible?


    Hi all

    I'm building a certain RPM package that must require an old version of that same package in order to be installed/upgraded. Is this possible?

    For example:
    For a package foo v5, somewhere in the spec file:
    "Requires: foo >= 4"

    I'm declaring this on the Requires tag of the spec file, but when I try to install or upgrade the package (without having the previous required version installed) I get no dependency error! As for other dependencies it all works fine.

    If, instead, I create a package named "bar" that "Requires: foo >= 4", when installing I do get the expected dependency error. I'm thinking it's not possible to require an old version of the same package. Is it so? Any thoughts on this?

    Thanks in advance!

  2. #2
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,221
    I dont think it is possible.

    Because:
    The package v5 you are installing, does *provide* a version >= 4 at install time, thus fullfilling the requirement.

    I am not so sure, that a dependency on an older package is a good way.
    Because:
    RPMs define a system (so to say).
    So, regardless if you install a new box or update an existing one, both should have the same files (binary, library, man, etc) and same version.

    This way you can guarantee consistency throughout your systems.


    What you maybe can do:
    1) split your RPM into v4 and v5 version, and let RPMs have dependency on the correct version
    2) or maybe check in the %pre or %post section for needed (data?) files and at least complain if nothing is found

    Cant really recommend something specific, as I dont know enough about the exact problem.
    But from the two approaches: 2) is the crappy one
    You must always face the curtain with a bow.

  3. #3
    Just Joined!
    Join Date
    Dec 2006
    Posts
    5
    Thank you for your tips Irithori!

    Quote Originally Posted by Irithori View Post
    The package v5 you are installing, does *provide* a version >= 4 at install time, thus fullfilling the requirement.
    It makes sense! It's funny, though, that I tried to install a version10 requiring a version20, and it still installed anyway. Since version10 does not provide a version >= 20... shouldn't it have failed? Hmm.. perhaps I need some more testing.


    Quote Originally Posted by Irithori View Post
    I am not so sure, that a dependency on an older package is a good way.
    Yes, I totally agree with your thoughts on this too. Usually, I proceed that way, but this time I'm dealing with database packaging, which is a bit more complex. I have a set of SQL files that are run by the RPM creating a database, it's tables, functions, users, etc. Its all fine, but when we have an upgrade I find it very hard to manage (and upgrades may involve inserting data as well - immutable data that "belongs" to the information model). Therefore, I decided it would be easier if I just install the differences (updates) from the previous version, instead of trying to maintain a whole working version every time that could be installed from scratch. So, to assure database status consistency, I needed to require the previous version when upgrading.
    If you or anyone have better suggestions for doing this - packaging databases - I'd appreciate!

    I'm not sure I totally understood your approach 1) (and, like you, I'm not very fond of solution 2)). But, based on what I thought you said , I'm now trying this, relying on full names instead of versions:

    packageA_v1
    Provides: packageA_v1

    packageA_v2
    Provides: packageA_v2
    Requires: packageA_v1

    It's not a fancy solution and it requires a lot of package version/naming discipline.. but.... I think it will do the job. What do you think?



    Thanks!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •