Results 1 to 4 of 4

Thread: Value of '%_transaction_color' in rpm macros

  1. #1
    Join Date
    Mar 2014
    Location
    Bangalore
    Posts
    2

    Default Value of '%_transaction_color' in rpm macros

    Hi,
    While going through the macros file regarding an update problem, i found that the value of '%_transaction_color' is set to 0.
    After searching a bit i found that by default rpm macros should have that specific value as 3.
    http://rpm.org/api/4.4.2.2/config_macros.html
    I also learnt that Suse uses specific methods to access the rpm and not by arch coloring.
    So, please can anyone tell me if the transaction color value should be 0 or should i change it according to the default rpm config.
    Thank you.

  2. #2

    Default Re: Value of '%_transaction_color' in rpm macros

    Quote Originally Posted by Exodus_69 View Post
    Hi,
    While going through the macros file regarding an update problem, i found that the value of '%_transaction_color' is set to 0.
    And what "update problem" did you have exactly?

    Yes, '%_transaction_color' seems to be set to 0 by default. AFAICS this setting is done specifically for each arch in /usr/lib/rpm/platform/xxx/macros.
    And I never had a problem with that AFAIK.

    I also learnt that Suse uses specific methods to access the rpm and not by arch coloring.
    Sorry, I don't understand that sentence at all.

    What do you mean with "access the rpm"?
    What does "accessing the rpm" have to do with "arch coloring"?

    PS: That "default configuration" you linked to is from 2005 and apparently from rpm 4.4.2.2 if I read it correctly. We have 2015 now and openSUSE 13.2 uses rpm 4.11. Things might have changed upstream meanwhile...

    At least on a quick look I don't find any patch related to that (or a custom macros file) in openSUSE 13.2's rpm package.
    And I looked at the included (upstream) 4.11.3 tarball as well, and macros does not set %_transaction_color at all there either.

    There's only this patch that apparently disables file coloring completely when _transaction_color is set to 0:
    https://build.opensuse.org/package/v....diff?expand=1

    And AFAICT (I'm not sure as those files are not included verbatim, they get created dynamically during the build) the platform macros files are changed as well, at least for x86_64 (this indeed seems to set %_transaction_colors to 3 upstream), i686 sets it to 0 even upstream.
    Ah well, here's apparently the (open)SUSE patch that sets it to 0 for all platforms: https://build.opensuse.org/package/v....diff?expand=1
    Last edited by wolfi323; 09-Jan-2015 at 04:11.

  3. #3
    Join Date
    Mar 2014
    Location
    Bangalore
    Posts
    2

    Default Re: Value of '%_transaction_color' in rpm macros

    Thank you for your answer.

    The problem i was having regarding updating the rpm packages was, every time i tried to update the packages, i got an error saying ImageMagick not installed.
    Whereas, yast software management showed it was installed. Anyway, it got fixed by simply rebuilding the rpm db.

    I am very sorry for "accessing the rpm". It should have been "using the rpm".

    I came to know this here.

    http://blog.gmane.org/gmane.linux.su...0071001/page=8


    Thanks again.

  4. #4

    Default Re: Value of '%_transaction_color' in rpm macros

    Quote Originally Posted by Exodus_69 View Post
    The problem i was having regarding updating the rpm packages was, every time i tried to update the packages, i got an error saying ImageMagick not installed.
    Whereas, yast software management showed it was installed. Anyway, it got fixed by simply rebuilding the rpm db.
    So your problem is solved now?

    Then it probably was "just" a corrupted rpm database, I suppose...

    I am very sorry for "accessing the rpm". It should have been "using the rpm".
    No problem.
    I just wasn't sure what you mean. And even "using the rpm" wouldn't have cleared up much about your actual problem...

    In such cases, it's probably good to provide more information about the exact circumstances or the actual problem at hand.

    Anyway, if you solved your problem, good to hear...

Posting Permissions

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