Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: Questions about best practices in downgrading / pinning

  1. #11
    Join Date
    Mar 2007
    Location
    Caprica
    Beans
    1,995
    Distro
    Ubuntu Development Release

    Re: Questions about best practices in downgrading / pinning

    Quote Originally Posted by mc4man View Post
    My self still think in a dev install the easiest way to downgrade is to simply acquire the needed packages & use dpkg, doesn't seem a "hack", just common sense.
    As far as pinning that's just personal choice I guess - obviously the easiest method is just to not upgrade packages one has downgraded
    I agree with you. I find it easier to just get the deb I want via wget and dpkg install it.
    Quote Originally Posted by mc4man View Post
    As in the example of nautilus one would still need to understated the various nautilus packages & relationships. So what will happen if you downgrade the nautilus package itself or pin an earlier version & let others update?
    Yep, which is why I mentioned looking at depends/rdepends via dpkg-query. That's where I'm not too confident yet. It's a question I also have, which I am about to test (as soon as I finish some other stuff). I believe that if "nautilus version n" pkg is pinned, packages that depend on "nautilus version n+1" will show on apt-get update&&apt-get upgrade but they won't be upgraded, because dependencies are not met (nautilus version n+1 won't ever be installed unless the pin is removed). I'm considering looking at the solutions proposed by aptitude --full-resolver to verify this in more detail.

    However, I'm just guessing. I haven't tested it enough times to be completely sure.

    Another example, using the situation proposed by Ventrical: We pinned linux-image*, but we haven't pinned linux-headers*, etc.


    Regards,
    Effenberg

  2. #12
    Join Date
    Jun 2007
    Beans
    12,734

    Re: Questions about best practices in downgrading / pinning

    I mentioned nautilus because it's a decent ex.
    You'll notice nautilus's dep on nautilus-data -
    >=1:3.5, <1:3.6
    That doesn't guarantee that nautilus 3.5.3 (last pre-me), will actually work with nautilus-data 3.5.X where X is >3
    or that any 3.5.X will work with ..data 3.5.X when the X's are different

  3. #13
    Join Date
    Mar 2007
    Location
    Caprica
    Beans
    1,995
    Distro
    Ubuntu Development Release

    Re: Questions about best practices in downgrading / pinning

    Quote Originally Posted by mc4man View Post
    I mentioned nautilus because it's a decent ex.
    You'll notice nautilus's dep on nautilus-data -
    >=1:3.5, <1:3.6
    I see, I haven't seen this until you mentioned it:
    Code:
    Package: nautilus
    Version: 1:3.5.5-0ubuntu3
    Depends: [...]nautilus-data (>= 1:3.5), nautilus-data (<< 1:3.6)[...]
    Quote Originally Posted by mc4man View Post
    That doesn't guarantee that nautilus 3.5.3 (last pre-me), will actually work with nautilus-data 3.5.X where X is >3
    or that any 3.5.X will work with ..data 3.5.X when the X's are different
    Sorry, you lost me Let me try to understand: It says it needs 3.5.* <= x < 3.6.*. Ok, we have the following at https://launchpad.net/ubuntu/quantal...nautilus-data:

    Code:
    3.5.1-0ubuntu1
    3.5.1-0ubuntu2
    3.5.1-0ubuntu3
    3.5.1-0ubuntu4
    3.5.1-0ubuntu5
    3.5.1-0ubuntu6
    3.5.2-0ubuntu2
    3.5.2-0ubuntu3
    3.5.3-0ubuntu1
    3.5.4-0ubuntu1
    3.5.4-0ubuntu2
    3.5.4-0ubuntu3
    3.5.5-0ubuntu1
    3.5.5-0ubuntu2
    3.5.5-0ubuntu3
    3.5.90-0ubuntu1
    All of them are within the range, so we wouldn't have broken deps with any of them. All were deleted / superseeded and the latest (1:3.5.90-0ubuntu1) is on repos right now. But it still fits the range. Then why wouldn't it work?

    Do you mean work in the sense of the programs that are within the pkgs functioning correctly or work in the sense of broken/not-broken deps?

    Regards,
    Effenberg

    PS: It's late and I'm very tired. I'm not even understanding Ubuntu pictograms anymore. I'm obviously missing something you already said... I'll look at it again after a night of sleep.
    Last edited by effenberg0x0; August 23rd, 2012 at 06:57 AM.

  4. #14
    Join Date
    Jun 2007
    Beans
    12,734

    Re: Questions about best practices in downgrading / pinning

    I guess the simplest demo would be just mismatch versions of nautilus & nautilus-data. So for instance
    3.5.5-0ubuntu3 <nautilus> pinned or downgraded
    3.5.90-0ubuntu1 <nautilus-data> current version

    or in the example of ventrical, he likely had
    3.5.3-0ubuntu1 <nautilus> pinned
    so then up nautilus-data, not pinned, to current of 3.5.90-0ubuntu1

    At least here on re-login nautilus would fail

    So here where I'm always altering nautilus a bit I keep all source packages at same source version (3 - 6 packages depending on whether -dev's ,dbg are installed), irregardless of whether the deps require or not

  5. #15
    Join Date
    Sep 2010
    Location
    Beta Testing in Canada
    Beans
    5,205
    Distro
    Ubuntu Development Release

    Re: Questions about best practices in downgrading / pinning

    Quote Originally Posted by mc4man View Post
    My self still think in a dev install the easiest way to downgrade is to simply acquire the needed packages & use dpkg, doesn't seem a "hack", just common sense.
    As far as pinning that's just personal choice I guess - obviously the easiest method is just to not upgrade packages one has downgraded

    As in the example of nautilus one would still need to understated the various nautilus packages & relationships. So what will happen if you downgrade the nautilus package itself or pin an earlier version & let others update?
    Thanks mac4man and effenberg. I tired to do this with a version of Edubuntu but I used a different method. I tried to use synaptic to pin and 'force' versions but that did not work as it had busted pipes and depends to other objects and modules. I am going to study effenbergs script a little bit more. I think it is important. Also with xsever-xorg. I had it working and then when the nvidia-current driver would not work with 1.13 it really broke one of my desktops pretty bad. My fault because I skipped a few steps.

    @effenberg

    Don't worry too much about giving me instrutions and even if I bork a desktop because I have so many PCs running. I import all my important stuff so I'm not loosing any data if I scratch any particular desktop. Thanks very much. I think this is an interesting subject that some of us should keep investigating.
    This is Rolling Release
    Warnings for New Beta Testers& Helpful Terminal Commands:
    Running Trusty /devel/@ 5.120GHz32bit/ Please put [ prefix] on New Threads!

  6. #16
    Join Date
    Jun 2010
    Location
    Berlin
    Beans
    305
    Distro
    Ubuntu Development Release

    Re: Questions about best practices in downgrading / pinning

    thanks for these great posts
    just spent a few days having to do upgrades using synaptic instead of the terminal because of the nvidia-current weirdness!
    i locked the package in synaptic then discovered it didn't transfer over into apt-get!
    i fast google-search and 3 different ubuntu references to this and one other thread
    super

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

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