Re: Pining for Qt 5.4
On Fri, May 01, 2015 at 08:28:26AM +0200, Markus-Hermann Koch wrote: > Hi folks! > I would like to use Qt 5.4 for its QOpenGLWidget. However, > Qt 5.4 is still stuck in experimental. Being a user I now seem to have > several options: ... > What would you do? Personally, I'd fire up a Debian docker container (or an Lxc container, or a plain ol' chroot) and install the package from experimental in there. Since you are developing an X app, one would then have some setup to do so that you could launch X programs in the container and have them display locally. Some of the methods to achieve that might not work with hardware acceleration, which would defeat the purpose in your case. The reason I'd do that is so my base system stays 'clean' and I don't create a situation where I have a dependency mess to tidy up, or accidentally break something else (e.g. QT apps installed that require < 5.4 for some reason) -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150503095744.gc29...@chew.redmars.org
Re: Pining for Qt 5.4
Hello Christian, > My guess is that in your previous attempt you added experimental to > your sources.list but didn't pin the release to a negative number, so > other packages might have automatically crept in in some cases, > screwing up your system that way. But if you pin experimental to a > negative number, you have to explicitly pin those packages that you > want back to a positive number in order for APT to consider them as > candidates for your system. Actually, even though I implicated it, I never installed experimental stuff on my system. And "Pining" is not "Pinning" -- I learned the latter word from you and the former one from Monty Python (the sketch with the dead parrot). "Pining for s.th." means something like "desiring deeply (in a heartfelt way)". What I _did_ do prior to said trauma was [!!!KIDS, DONT TRY THIS AT HOME!!!]: Add deb http://www.deb-multimedia.org jessie main non-free to my /etc/apt/sources.list and then bray apt-get update apt-get upgrade The effects were akin to what I imagine may happen if you simply set your whole system to experimental. Hundreds of packages were pulled in and, for instance, sound was broken. Having /home separated from the rest of the system and only just come from another distro I decided it was simplest to reinstall. This was last Christmas and I have been happy ever since, successfully avoiding even 'testing'. To the issue: My acute Qt problem is solved since I finally found I could install Qt 5.4 locally in home and then have CMake find it setting the CMAKE_PREFIX_PATH accordingly (i.e. in my case to "/home/kochmn/sw/Qt/Qt_5_4/5.4/gcc_64/lib/cmake/Qt5Widgets" the Widgets package pulling in all other dependencies). I will keep "pinning" and the "apt-cache policy" in mind though and come back to your mails when I ever need a specific testing/experimental package without being ready to flame up my whole system. Thanks again to you and all others answering my question! Cheers, Markus. P.S.: I already unsubscribed from this mailing list again because I felt it was really spamming my mailbox with lots of stuff I did not even understand what people are talking about. Is there a way to configure it thus that it only forwards answers to the user's own posts to that user's mailbox? On 02.05.2015 16:57, Christian Seiler wrote: > On 05/02/2015 04:00 PM, Markus-Hermann Koch wrote: >> thanks for your detailed answer! >> >> Sigh. I am still hoping to avoid experimental on this one (being >> already traumatized from past experiences culminating in complete >> reinstallation into my now clean 'unstable' system with its single >> media package libdvdcss2). > > Well, if you do pin experimental packages to -1 by default, APT will > never install them, even if you ask it to. > > For example, if I want to install libkf5config-dev (only in > experimental so far), have experimental in my sources.list.d but also > pinned to -1, using APT has the following result: > > # apt-get install libkf5config-dev > Reading package lists... Done > Building dependency tree > Reading state information... Done > Package libkf5config-dev is not available, but is referred to by another > package. > This may mean that the package is missing, has been obsoleted, or > is only available from another source > > E: Package 'libkf5config-dev' has no installation candidate > > This means that no packages from experimental can be installed by > default, you have to explicitly pin them again to make certain packages > installable. > > On my own box, I did exactly the steps I wrote in my previous mail to > test the installation of Qt 5.4 (I'm running Jessie, Qt5 previously not > installed at all), and running apt-get install qt5-default it installed > Qt5 packages from experimental, but all other packages from Jessie. > > This works now because Qt 5.4 doesn't have any dependencies on stuff > that's only in experimental, so you will currently get ONLY Qt 5.4, but > everything else will be from other suits. > > Now, if at some point you want to install something from experimental > that does have additional deps on other experimental packages, you will > have the following stuff happen: > > - first you just pin the packages you want themselves to 500 > - then you try to install them with APT. that will tell you that it >can't resolve dependencies (and it will also tell you which ones) > - then you take a look at the dependencies you'd need from experimental >and see if you think you can live with that - if so, just add them >to the list of packages pinned to 500 (if you pin by releaese, you >can add the deps to the same list as the original package, if you pin >by version, you need to create a new block with the new version >number) > > My guess is that in your previous attempt you added experimental to your > sources.list but didn't pin the release to a negative number, so other > packages might have automatically crept in in some cases, scr
Re: Pining for Qt 5.4
On 05/02/2015 at 07:45 PM, Lisi Reisz wrote: > On Sunday 03 May 2015 00:40:17 Lisi Reisz wrote: > >> On Saturday 02 May 2015 23:56:30 The Wanderer wrote: >>> Given that the original poster's question did not include the >>> word "pin" in any form, and "pinning" did not enter the >>> discussion until Christian Seiler's first response, I think that >>> this _is_ what the Subject line is referring to. I suspect the >>> "pining"/"pinning" parallel here is in fact pure coincidence. >> >> I've just reread it. I think that you are right. > > Though I hasten to add that Christian's treatise on pinning was > extremely useful to me! To me as well. I've tagged all three of his posts in this thread as "noteworthy", and copied the first one (with the treatise in question) to a separate folder which I keep for particularly noteworthy things I may want to refer back to easily later. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Pining for Qt 5.4
On Sunday 03 May 2015 00:40:17 Lisi Reisz wrote: > On Saturday 02 May 2015 23:56:30 The Wanderer wrote: > > On 05/02/2015 at 06:33 PM, Lisi Reisz wrote: > > > On Saturday 02 May 2015 22:32:27 Bob Bernstein wrote: > > >> On Sat, 2 May 2015, Lisi Reisz wrote: > > >>> I have always had trouble getting my head round pinning [...] > > >> > > >> I've been reading the Subject: line of this thread as literally > > >> "pining," i.e. longing desperately for something that never > > >> arrives. > > > > > > I did for a while. ;-) > > > > > > Then I caught upon reading the list > > > > Given that the original poster's question did not include the word "pin" > > in any form, and "pinning" did not enter the discussion until Christian > > Seiler's first response, I think that this _is_ what the Subject line is > > referring to. I suspect the "pining"/"pinning" parallel here is in fact > > pure coincidence. > > I've just reread it. I think that you are right. Though I hasten to add that Christian's treatise on pinning was extremely useful to me! Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201505030045.03855.lisi.re...@gmail.com
Re: Pining for Qt 5.4
On Saturday 02 May 2015 23:56:30 The Wanderer wrote: > On 05/02/2015 at 06:33 PM, Lisi Reisz wrote: > > On Saturday 02 May 2015 22:32:27 Bob Bernstein wrote: > >> On Sat, 2 May 2015, Lisi Reisz wrote: > >>> I have always had trouble getting my head round pinning [...] > >> > >> I've been reading the Subject: line of this thread as literally > >> "pining," i.e. longing desperately for something that never > >> arrives. > > > > I did for a while. ;-) > > > > Then I caught upon reading the list > > Given that the original poster's question did not include the word "pin" > in any form, and "pinning" did not enter the discussion until Christian > Seiler's first response, I think that this _is_ what the Subject line is > referring to. I suspect the "pining"/"pinning" parallel here is in fact > pure coincidence. I've just reread it. I think that you are right. Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201505030040.17236.lisi.re...@gmail.com
Re: Pining for Qt 5.4
On 05/02/2015 at 06:33 PM, Lisi Reisz wrote: > On Saturday 02 May 2015 22:32:27 Bob Bernstein wrote: > >> On Sat, 2 May 2015, Lisi Reisz wrote: >> >>> I have always had trouble getting my head round pinning [...] >> >> I've been reading the Subject: line of this thread as literally >> "pining," i.e. longing desperately for something that never >> arrives. > > I did for a while. ;-) > > Then I caught upon reading the list Given that the original poster's question did not include the word "pin" in any form, and "pinning" did not enter the discussion until Christian Seiler's first response, I think that this _is_ what the Subject line is referring to. I suspect the "pining"/"pinning" parallel here is in fact pure coincidence. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Pining for Qt 5.4
On Saturday 02 May 2015 22:32:27 Bob Bernstein wrote: > On Sat, 2 May 2015, Lisi Reisz wrote: > > I have always had trouble getting my head round > > pinning [...] > > I've been reading the Subject: line of this thread as > literally "pining," i.e. longing desperately for > something that never arrives. I did for a while. ;-) Then I caught upon reading the list Lisi > > That wonderful line from the Monty Python Dead Parrot > sketch kept running in my head: "He's pining for the > fjords." > > -- > These are not the droids you are looking for. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201505022333.33661.lisi.re...@gmail.com
Re: Pining for Qt 5.4
On Sat, 2 May 2015, Lisi Reisz wrote: I have always had trouble getting my head round pinning [...] I've been reading the Subject: line of this thread as literally "pining," i.e. longing desperately for something that never arrives. That wonderful line from the Monty Python Dead Parrot sketch kept running in my head: "He's pining for the fjords." -- These are not the droids you are looking for. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.20.3.1505021727280.5...@arjgebyy.fvkgvrffheivibe.bet
Re: Pining for Qt 5.4
On Saturday 02 May 2015 16:36:30 Christian Seiler wrote: > On 05/02/2015 05:06 PM, Lisi Reisz wrote: > > Does the "-t wheezy-backports" format only work with backports? > > No, it works here as well. From the manpage of apt-get: > > This option controls the default input to the policy engine; it > > creates a default pin at priority 990 using the specified release > > string. > > This means that ALL packages from that suit will get 990 priority (which > is really high, see the apt_preferences(5) manpage). This has the > consequence that if you do that for experimental, ALL dependencies of a > package will then also come from experimental (because -t affects the > WHOLE apt-get run, not just a single package). For backports it's > generally OK, but for other things such as running testing with 1 or 2 > packages from experimental, it can be very problematic. > > To give you an example of the consequences: > > - package libA is version 1 in stable, version 2~bpo in > stable-backports. > - package libD is version 10 in stable and version 11~bpo in > stable-backports > - package B is version 23 in stable and version 24~bpo in > stable-backports > - both versions require libA in any version >= 1 > - version 24~bpo additionally requires libD >= 11~bpo >(version 23 didn't require libD at all) > - package C is version 42 in stable and version 50~bpo in > stable-backports > - version 42 requires libA with version >= 1 > - version 50~bpo requires libA with version >= 2~bpo > > If you now just want to install package B from backports (but are > uninterested in C), and neither of the four packages mentioned is > installed yet, you can do that in two ways: > > 1. pin D from backports to priority 500, then try to install it, APT > will complain about libD not being installed in the correct version, > you then pin libD from backports to priority 500 and then you can > install the package > > => libD and B will be from backports > => libA is still from stable, because B doesn't require a newer >version > > 2. apt-get install -t stable-backports B > > => both libA and libD will also be taken from backports > > Now with backports this is typically fine (because the aforementioned > case is also very rare when it comes to backports, and even if it does > happen, libraries in backports are typically not that prone to causing > problems), but for experimental - or worse yet, other repositories, this > can be something you really, really don't want. > > (Doesn't have to be libraries btw., can be any dependency.) > > Therefore: use apt-get install -t with great care. It's probably fine > for backports, but don't use it for anything else unless you REALLY know > what you are doing. Thanks again, Christian. That is really helpful and lucid. I have always had trouble getting my head round pinning, for some reason. Not the concepts, but actually doing it. Thanks to you today, light has dawned. I'm very grateful. Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201505021644.29372.lisi.re...@gmail.com
Re: Pining for Qt 5.4
On 05/02/2015 05:06 PM, Lisi Reisz wrote: > Does the "-t wheezy-backports" format only work with backports? No, it works here as well. From the manpage of apt-get: > This option controls the default input to the policy engine; it > creates a default pin at priority 990 using the specified release > string. This means that ALL packages from that suit will get 990 priority (which is really high, see the apt_preferences(5) manpage). This has the consequence that if you do that for experimental, ALL dependencies of a package will then also come from experimental (because -t affects the WHOLE apt-get run, not just a single package). For backports it's generally OK, but for other things such as running testing with 1 or 2 packages from experimental, it can be very problematic. To give you an example of the consequences: - package libA is version 1 in stable, version 2~bpo in stable-backports. - package libD is version 10 in stable and version 11~bpo in stable-backports - package B is version 23 in stable and version 24~bpo in stable-backports - both versions require libA in any version >= 1 - version 24~bpo additionally requires libD >= 11~bpo (version 23 didn't require libD at all) - package C is version 42 in stable and version 50~bpo in stable-backports - version 42 requires libA with version >= 1 - version 50~bpo requires libA with version >= 2~bpo If you now just want to install package B from backports (but are uninterested in C), and neither of the four packages mentioned is installed yet, you can do that in two ways: 1. pin D from backports to priority 500, then try to install it, APT will complain about libD not being installed in the correct version, you then pin libD from backports to priority 500 and then you can install the package => libD and B will be from backports => libA is still from stable, because B doesn't require a newer version 2. apt-get install -t stable-backports B => both libA and libD will also be taken from backports Now with backports this is typically fine (because the aforementioned case is also very rare when it comes to backports, and even if it does happen, libraries in backports are typically not that prone to causing problems), but for experimental - or worse yet, other repositories, this can be something you really, really don't want. (Doesn't have to be libraries btw., can be any dependency.) Therefore: use apt-get install -t with great care. It's probably fine for backports, but don't use it for anything else unless you REALLY know what you are doing. Christian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5544eefe.7080...@iwakd.de
Re: Pining for Qt 5.4
On Saturday 02 May 2015 15:57:49 Christian Seiler wrote: > On 05/02/2015 04:00 PM, Markus-Hermann Koch wrote: > > thanks for your detailed answer! > > > > Sigh. I am still hoping to avoid experimental on this one (being > > already traumatized from past experiences culminating in complete > > reinstallation into my now clean 'unstable' system with its single > > media package libdvdcss2). > > Well, if you do pin experimental packages to -1 by default, APT will > never install them, even if you ask it to. > > For example, if I want to install libkf5config-dev (only in > experimental so far), have experimental in my sources.list.d but also > pinned to -1, using APT has the following result: > > # apt-get install libkf5config-dev > Reading package lists... Done > Building dependency tree > Reading state information... Done > Package libkf5config-dev is not available, but is referred to by another > package. > This may mean that the package is missing, has been obsoleted, or > is only available from another source > > E: Package 'libkf5config-dev' has no installation candidate > > This means that no packages from experimental can be installed by > default, you have to explicitly pin them again to make certain packages > installable. > > On my own box, I did exactly the steps I wrote in my previous mail to > test the installation of Qt 5.4 (I'm running Jessie, Qt5 previously not > installed at all), and running apt-get install qt5-default it installed > Qt5 packages from experimental, but all other packages from Jessie. > > This works now because Qt 5.4 doesn't have any dependencies on stuff > that's only in experimental, so you will currently get ONLY Qt 5.4, but > everything else will be from other suits. > > Now, if at some point you want to install something from experimental > that does have additional deps on other experimental packages, you will > have the following stuff happen: > > - first you just pin the packages you want themselves to 500 > - then you try to install them with APT. that will tell you that it >can't resolve dependencies (and it will also tell you which ones) > - then you take a look at the dependencies you'd need from experimental >and see if you think you can live with that - if so, just add them >to the list of packages pinned to 500 (if you pin by releaese, you >can add the deps to the same list as the original package, if you pin >by version, you need to create a new block with the new version >number) > > My guess is that in your previous attempt you added experimental to your > sources.list but didn't pin the release to a negative number, so other > packages might have automatically crept in in some cases, screwing up > your system that way. But if you pin experimental to a negative number, > you have to explicitly pin those packages that you want back to a > positive number in order for APT to consider them as candidates for your > system. > > > Still: If I can make your priority based updating work and if it > > does not require pulling too important other testing/experimental > > libraries into my system I will give it a shot. > > As I said: currently Qt 5.4 is installable without any deps on stuff > that's not already in unstable. > > > If you understand what pinning does (and what different priority ranges > mean), then you can use that to selectively install packages from > different suits / different repositories without having the risk that > other packages from those repositories 'contaminate' your system. You > only have to keep in mind that 'apt-cache policy' is your friend if APT > complains about stuff, because with that you can check what's going on. Does the "-t wheezy-backports" format only work with backports? Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201505021606.40337.lisi.re...@gmail.com
Re: Pining for Qt 5.4
P.S.: Feeling sheepish... Reading Frederics answer I tried the .run again. No idea what I did wrong yesterday, this time a Qt window popped up, asking me where I want the Qt 5.4 installation to be put. This is exactly what I wanted. Thanks again! Cheers, Markus. On 02.05.2015 15:11, Christian Seiler wrote: > On 05/01/2015 08:28 AM, Markus-Hermann Koch wrote: >> I would like to use Qt 5.4 for its QOpenGLWidget. However, >> Qt 5.4 is still stuck in experimental. Being a user I now seem to have >> several options: [...] >> >> What would you do? > > 5. Install the packages from experimental. > > If you really want to be on the safe side, you can do the following to > make sure it's just Qt 5.4 from experimental and nothing else: > > A. Create /etc/apt/sources.list.d/experimental.list (or similar name) >with the following contents (if you already have unstable in your >list, just add experimental): > > deb http://http.debian.net/debian unstable main > deb http://http.debian.net/debian experimental main > > (You can use your default mirror here instead of http.debian.net, if > you so desire.) > > B. Pin unstable and experimental packages to priority -1 by default, >so that they can't be installed by accident. Do this by creating >/etc/apt/preferences.d/01experimental with the following contents: > > Package: * > Pin: release n=experimental,o=Debian > Pin-Priority: -1 > > Package: * > Pin: release n=sid,o=Debian > Pin-Priority: -1 > > (IMPORTANT: leave out the 2nd one if you are already using unstable, > else no packages from unstable will be upgradable!) > > C. Selectively pin the Qt5 packages to a higher priority (500 is >usually what you want) so that they are taken from experimental. > > You can do this in two ways: make _any_ version of the packages from > experimental be installable or just make the _current_ version from > experimental installable. The former has the advantage that if there are > further bugfixes in newer Qt5.4 versions while it still isn't in > unstable, apt will automatically be willing to upgrade to those > versions. It has the disadvantage that if a really new and really > experimental version of Qt5 is uploaded to experimental at some point in > the future, APT will automatically choose that one. > > The priority 500 is chosen in such a way that it's the same as the > default package priority of stable/testing/unstable, so that if one of > those suits starts to contain a package with a higher version number > (for example, Qt 5.4 is uploaded to unstable with some additional fixes > at some point in the future), APT will be willing to upgrade that. > > In any case, create a file /etc/apt/preferences.d/50qt5.4 with the > following contents: > > For making any version that's currently in experimental installable: > > Package: libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 > libqt5network5 libqt5opengl5 libqt5opengl5-dev libqt5printsupport5 > libqt5sql5 libqt5sql5-mysql libqt5sql5-odbc libqt5sql5-psql > libqt5sql5-sqlite libqt5sql5-tds libqt5test5 libqt5widgets5 > libqt5xml5 qt5-default qt5-qmake qtbase5-dbg qtbase5-dev > qtbase5-dev-tools qtbase5-dev-tools-dbg qtbase5-doc-html > qtbase5-examples qtbase5-examples-dbg qtbase5-private-dev > Pin: release n=experimental,o=Debian > Pin-Priority: 500 > > For choosing the specific version that's currently in experimental: > > Package: libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 > libqt5network5 libqt5opengl5 libqt5opengl5-dev libqt5printsupport5 > libqt5sql5 libqt5sql5-mysql libqt5sql5-odbc libqt5sql5-psql > libqt5sql5-sqlite libqt5sql5-tds libqt5test5 libqt5widgets5 > libqt5xml5 qt5-default qt5-qmake qtbase5-dbg qtbase5-dev > qtbase5-dev-tools qtbase5-dev-tools-dbg qtbase5-doc-html > qtbase5-examples qtbase5-examples-dbg qtbase5-private-dev > Pin: version 5.4.1+dfsg-2 > Pin-Priority: 500 > > (You can include the line breaks in the package list as long as the > continuation lines start with a space. The packages listed here are all > the binary packages that Qt5's source package.[1]) > > D. Test that your pinning works. Run apt-get update to update your >package lists and then try out: > > apt-cache policy libqt5-core5a > This should print 'Candidate: 5.4.1+dfsg-2" to show that APT would like > to install that version of the package. > > Then try another package in experimental, e.g. libkf5config-dev (not in > unstable/testing yet): > apt-get policy libkf5config-dev > This should print 'Candidate: (none)' to show that even though a version > is available, APT doesn't want to install it, because you pinned > experimental to -1. > > E. Finally, run apt-get upgrade / install of the Qt5 packages you want. > > Christian > > [1] Taken from: > https://packages.debian.org/source/experimental/qtbase-opensource-src > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Arch
Re: Pining for Qt 5.4
On 05/02/2015 04:00 PM, Markus-Hermann Koch wrote: > thanks for your detailed answer! > > Sigh. I am still hoping to avoid experimental on this one (being > already traumatized from past experiences culminating in complete > reinstallation into my now clean 'unstable' system with its single > media package libdvdcss2). Well, if you do pin experimental packages to -1 by default, APT will never install them, even if you ask it to. For example, if I want to install libkf5config-dev (only in experimental so far), have experimental in my sources.list.d but also pinned to -1, using APT has the following result: # apt-get install libkf5config-dev Reading package lists... Done Building dependency tree Reading state information... Done Package libkf5config-dev is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'libkf5config-dev' has no installation candidate This means that no packages from experimental can be installed by default, you have to explicitly pin them again to make certain packages installable. On my own box, I did exactly the steps I wrote in my previous mail to test the installation of Qt 5.4 (I'm running Jessie, Qt5 previously not installed at all), and running apt-get install qt5-default it installed Qt5 packages from experimental, but all other packages from Jessie. This works now because Qt 5.4 doesn't have any dependencies on stuff that's only in experimental, so you will currently get ONLY Qt 5.4, but everything else will be from other suits. Now, if at some point you want to install something from experimental that does have additional deps on other experimental packages, you will have the following stuff happen: - first you just pin the packages you want themselves to 500 - then you try to install them with APT. that will tell you that it can't resolve dependencies (and it will also tell you which ones) - then you take a look at the dependencies you'd need from experimental and see if you think you can live with that - if so, just add them to the list of packages pinned to 500 (if you pin by releaese, you can add the deps to the same list as the original package, if you pin by version, you need to create a new block with the new version number) My guess is that in your previous attempt you added experimental to your sources.list but didn't pin the release to a negative number, so other packages might have automatically crept in in some cases, screwing up your system that way. But if you pin experimental to a negative number, you have to explicitly pin those packages that you want back to a positive number in order for APT to consider them as candidates for your system. > Still: If I can make your priority based updating work and if it > does not require pulling too important other testing/experimental > libraries into my system I will give it a shot. As I said: currently Qt 5.4 is installable without any deps on stuff that's not already in unstable. If you understand what pinning does (and what different priority ranges mean), then you can use that to selectively install packages from different suits / different repositories without having the risk that other packages from those repositories 'contaminate' your system. You only have to keep in mind that 'apt-cache policy' is your friend if APT complains about stuff, because with that you can check what's going on. Christian -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5544e5ed.6030...@iwakd.de
Re: Pining for Qt 5.4
On Saturday 02 May 2015 14:11:30 Christian Seiler wrote: > On 05/01/2015 08:28 AM, Markus-Hermann Koch wrote: > > I would like to use Qt 5.4 for its QOpenGLWidget. However, > > Qt 5.4 is still stuck in experimental. Being a user I now seem to have > > several options: [...] > > > > What would you do? > > 5. Install the packages from experimental. > > If you really want to be on the safe side, you can do the following to > make sure it's just Qt 5.4 from experimental and nothing else: > > A. Create /etc/apt/sources.list.d/experimental.list (or similar name) >with the following contents (if you already have unstable in your >list, just add experimental): > > deb http://http.debian.net/debian unstable main > deb http://http.debian.net/debian experimental main > > (You can use your default mirror here instead of http.debian.net, if > you so desire.) > > B. Pin unstable and experimental packages to priority -1 by default, >so that they can't be installed by accident. Do this by creating >/etc/apt/preferences.d/01experimental with the following contents: > > Package: * > Pin: release n=experimental,o=Debian > Pin-Priority: -1 > > Package: * > Pin: release n=sid,o=Debian > Pin-Priority: -1 > > (IMPORTANT: leave out the 2nd one if you are already using unstable, > else no packages from unstable will be upgradable!) > > C. Selectively pin the Qt5 packages to a higher priority (500 is >usually what you want) so that they are taken from experimental. > > You can do this in two ways: make _any_ version of the packages from > experimental be installable or just make the _current_ version from > experimental installable. The former has the advantage that if there are > further bugfixes in newer Qt5.4 versions while it still isn't in > unstable, apt will automatically be willing to upgrade to those > versions. It has the disadvantage that if a really new and really > experimental version of Qt5 is uploaded to experimental at some point in > the future, APT will automatically choose that one. > > The priority 500 is chosen in such a way that it's the same as the > default package priority of stable/testing/unstable, so that if one of > those suits starts to contain a package with a higher version number > (for example, Qt 5.4 is uploaded to unstable with some additional fixes > at some point in the future), APT will be willing to upgrade that. > > In any case, create a file /etc/apt/preferences.d/50qt5.4 with the > following contents: > > For making any version that's currently in experimental installable: > > Package: libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 > libqt5network5 libqt5opengl5 libqt5opengl5-dev libqt5printsupport5 > libqt5sql5 libqt5sql5-mysql libqt5sql5-odbc libqt5sql5-psql > libqt5sql5-sqlite libqt5sql5-tds libqt5test5 libqt5widgets5 > libqt5xml5 qt5-default qt5-qmake qtbase5-dbg qtbase5-dev > qtbase5-dev-tools qtbase5-dev-tools-dbg qtbase5-doc-html > qtbase5-examples qtbase5-examples-dbg qtbase5-private-dev > Pin: release n=experimental,o=Debian > Pin-Priority: 500 > > For choosing the specific version that's currently in experimental: > > Package: libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 > libqt5network5 libqt5opengl5 libqt5opengl5-dev libqt5printsupport5 > libqt5sql5 libqt5sql5-mysql libqt5sql5-odbc libqt5sql5-psql > libqt5sql5-sqlite libqt5sql5-tds libqt5test5 libqt5widgets5 > libqt5xml5 qt5-default qt5-qmake qtbase5-dbg qtbase5-dev > qtbase5-dev-tools qtbase5-dev-tools-dbg qtbase5-doc-html > qtbase5-examples qtbase5-examples-dbg qtbase5-private-dev > Pin: version 5.4.1+dfsg-2 > Pin-Priority: 500 > > (You can include the line breaks in the package list as long as the > continuation lines start with a space. The packages listed here are all > the binary packages that Qt5's source package.[1]) > > D. Test that your pinning works. Run apt-get update to update your >package lists and then try out: > > apt-cache policy libqt5-core5a > This should print 'Candidate: 5.4.1+dfsg-2" to show that APT would like > to install that version of the package. > > Then try another package in experimental, e.g. libkf5config-dev (not in > unstable/testing yet): > apt-get policy libkf5config-dev > This should print 'Candidate: (none)' to show that even though a version > is available, APT doesn't want to install it, because you pinned > experimental to -1. > > E. Finally, run apt-get upgrade / install of the Qt5 packages you want. > > Christian > > [1] Taken from: > https://packages.debian.org/source/experimental/qtbase-opensource-src Thanks, Christian.. That is a great explanation of pinning. Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201505021533.42924.lisi.re...@gmail.com
Re: Pining for Qt 5.4
Hi Christian, thanks for your detailed answer! Sigh. I am still hoping to avoid experimental on this one (being already traumatized from past experiences culminating in complete reinstallation into my now clean 'unstable' system with its single media package libdvdcss2). Still: If I can make your priority based updating work and if it does not require pulling too important other testing/experimental libraries into my system I will give it a shot. At the very least I will be motivated to understand your hints and to read https://wiki.debian.org/AptPreferences Cheers, Markus. On 02.05.2015 15:11, Christian Seiler wrote: > On 05/01/2015 08:28 AM, Markus-Hermann Koch wrote: >> I would like to use Qt 5.4 for its QOpenGLWidget. However, >> Qt 5.4 is still stuck in experimental. Being a user I now seem to have >> several options: [...] >> >> What would you do? > > 5. Install the packages from experimental. > > If you really want to be on the safe side, you can do the following to > make sure it's just Qt 5.4 from experimental and nothing else: > > A. Create /etc/apt/sources.list.d/experimental.list (or similar name) >with the following contents (if you already have unstable in your >list, just add experimental): > > deb http://http.debian.net/debian unstable main > deb http://http.debian.net/debian experimental main > > (You can use your default mirror here instead of http.debian.net, if > you so desire.) > > B. Pin unstable and experimental packages to priority -1 by default, >so that they can't be installed by accident. Do this by creating >/etc/apt/preferences.d/01experimental with the following contents: > > Package: * > Pin: release n=experimental,o=Debian > Pin-Priority: -1 > > Package: * > Pin: release n=sid,o=Debian > Pin-Priority: -1 > > (IMPORTANT: leave out the 2nd one if you are already using unstable, > else no packages from unstable will be upgradable!) > > C. Selectively pin the Qt5 packages to a higher priority (500 is >usually what you want) so that they are taken from experimental. > > You can do this in two ways: make _any_ version of the packages from > experimental be installable or just make the _current_ version from > experimental installable. The former has the advantage that if there are > further bugfixes in newer Qt5.4 versions while it still isn't in > unstable, apt will automatically be willing to upgrade to those > versions. It has the disadvantage that if a really new and really > experimental version of Qt5 is uploaded to experimental at some point in > the future, APT will automatically choose that one. > > The priority 500 is chosen in such a way that it's the same as the > default package priority of stable/testing/unstable, so that if one of > those suits starts to contain a package with a higher version number > (for example, Qt 5.4 is uploaded to unstable with some additional fixes > at some point in the future), APT will be willing to upgrade that. > > In any case, create a file /etc/apt/preferences.d/50qt5.4 with the > following contents: > > For making any version that's currently in experimental installable: > > Package: libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 > libqt5network5 libqt5opengl5 libqt5opengl5-dev libqt5printsupport5 > libqt5sql5 libqt5sql5-mysql libqt5sql5-odbc libqt5sql5-psql > libqt5sql5-sqlite libqt5sql5-tds libqt5test5 libqt5widgets5 > libqt5xml5 qt5-default qt5-qmake qtbase5-dbg qtbase5-dev > qtbase5-dev-tools qtbase5-dev-tools-dbg qtbase5-doc-html > qtbase5-examples qtbase5-examples-dbg qtbase5-private-dev > Pin: release n=experimental,o=Debian > Pin-Priority: 500 > > For choosing the specific version that's currently in experimental: > > Package: libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 > libqt5network5 libqt5opengl5 libqt5opengl5-dev libqt5printsupport5 > libqt5sql5 libqt5sql5-mysql libqt5sql5-odbc libqt5sql5-psql > libqt5sql5-sqlite libqt5sql5-tds libqt5test5 libqt5widgets5 > libqt5xml5 qt5-default qt5-qmake qtbase5-dbg qtbase5-dev > qtbase5-dev-tools qtbase5-dev-tools-dbg qtbase5-doc-html > qtbase5-examples qtbase5-examples-dbg qtbase5-private-dev > Pin: version 5.4.1+dfsg-2 > Pin-Priority: 500 > > (You can include the line breaks in the package list as long as the > continuation lines start with a space. The packages listed here are all > the binary packages that Qt5's source package.[1]) > > D. Test that your pinning works. Run apt-get update to update your >package lists and then try out: > > apt-cache policy libqt5-core5a > This should print 'Candidate: 5.4.1+dfsg-2" to show that APT would like > to install that version of the package. > > Then try another package in experimental, e.g. libkf5config-dev (not in > unstable/testing yet): > apt-get policy libkf5config-dev > This should print 'Candidate: (none)' to show that even though a version > is available, APT doesn't want to install it, because you pinned > experimental to -1. > > E. Finally, run
Re: Pining for Qt 5.4
On 05/01/2015 08:28 AM, Markus-Hermann Koch wrote: > I would like to use Qt 5.4 for its QOpenGLWidget. However, > Qt 5.4 is still stuck in experimental. Being a user I now seem to have > several options: [...] > > What would you do? 5. Install the packages from experimental. If you really want to be on the safe side, you can do the following to make sure it's just Qt 5.4 from experimental and nothing else: A. Create /etc/apt/sources.list.d/experimental.list (or similar name) with the following contents (if you already have unstable in your list, just add experimental): deb http://http.debian.net/debian unstable main deb http://http.debian.net/debian experimental main (You can use your default mirror here instead of http.debian.net, if you so desire.) B. Pin unstable and experimental packages to priority -1 by default, so that they can't be installed by accident. Do this by creating /etc/apt/preferences.d/01experimental with the following contents: Package: * Pin: release n=experimental,o=Debian Pin-Priority: -1 Package: * Pin: release n=sid,o=Debian Pin-Priority: -1 (IMPORTANT: leave out the 2nd one if you are already using unstable, else no packages from unstable will be upgradable!) C. Selectively pin the Qt5 packages to a higher priority (500 is usually what you want) so that they are taken from experimental. You can do this in two ways: make _any_ version of the packages from experimental be installable or just make the _current_ version from experimental installable. The former has the advantage that if there are further bugfixes in newer Qt5.4 versions while it still isn't in unstable, apt will automatically be willing to upgrade to those versions. It has the disadvantage that if a really new and really experimental version of Qt5 is uploaded to experimental at some point in the future, APT will automatically choose that one. The priority 500 is chosen in such a way that it's the same as the default package priority of stable/testing/unstable, so that if one of those suits starts to contain a package with a higher version number (for example, Qt 5.4 is uploaded to unstable with some additional fixes at some point in the future), APT will be willing to upgrade that. In any case, create a file /etc/apt/preferences.d/50qt5.4 with the following contents: For making any version that's currently in experimental installable: Package: libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5opengl5 libqt5opengl5-dev libqt5printsupport5 libqt5sql5 libqt5sql5-mysql libqt5sql5-odbc libqt5sql5-psql libqt5sql5-sqlite libqt5sql5-tds libqt5test5 libqt5widgets5 libqt5xml5 qt5-default qt5-qmake qtbase5-dbg qtbase5-dev qtbase5-dev-tools qtbase5-dev-tools-dbg qtbase5-doc-html qtbase5-examples qtbase5-examples-dbg qtbase5-private-dev Pin: release n=experimental,o=Debian Pin-Priority: 500 For choosing the specific version that's currently in experimental: Package: libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5opengl5 libqt5opengl5-dev libqt5printsupport5 libqt5sql5 libqt5sql5-mysql libqt5sql5-odbc libqt5sql5-psql libqt5sql5-sqlite libqt5sql5-tds libqt5test5 libqt5widgets5 libqt5xml5 qt5-default qt5-qmake qtbase5-dbg qtbase5-dev qtbase5-dev-tools qtbase5-dev-tools-dbg qtbase5-doc-html qtbase5-examples qtbase5-examples-dbg qtbase5-private-dev Pin: version 5.4.1+dfsg-2 Pin-Priority: 500 (You can include the line breaks in the package list as long as the continuation lines start with a space. The packages listed here are all the binary packages that Qt5's source package.[1]) D. Test that your pinning works. Run apt-get update to update your package lists and then try out: apt-cache policy libqt5-core5a This should print 'Candidate: 5.4.1+dfsg-2" to show that APT would like to install that version of the package. Then try another package in experimental, e.g. libkf5config-dev (not in unstable/testing yet): apt-get policy libkf5config-dev This should print 'Candidate: (none)' to show that even though a version is available, APT doesn't want to install it, because you pinned experimental to -1. E. Finally, run apt-get upgrade / install of the Qt5 packages you want. Christian [1] Taken from: https://packages.debian.org/source/experimental/qtbase-opensource-src -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5544cd02.4070...@iwakd.de
Re: Pining for Qt 5.4
On Friday 01 May 2015 08:28:26 Markus-Hermann Koch wrote: > Hi folks! > I would like to use Qt 5.4 for its QOpenGLWidget. However, > Qt 5.4 is still stuck in experimental. Being a user I now seem to have > several options: > > 2.) Grant root privileges to > ./qt-opensource-linux-x64-1.6.0-8-online.run (the linux installer from > www.qt.io) and see what happens. > Is that dangerous? I only ever installed the offline version and the last I installed on Debian Wheezy was qt 5.2 but it went smoothly. I don't remember I had to be root to install it but I may be wrong on this. The installer creates a Qt directory in your $HOME directory and copies the libraries, binaries, examples, documentation and QtCreator into it (for instance, the current version would be in $HOME/Qt/Qt5.4.1). You can install several versions of the Qt librairies and binaries. They all use distinct subdirectories in $HOME/Qt. As a consequence, you must not forget to manually unintall older versions when you don't need them any more. QtCreator is configured to detect existing Qt librairies on the system and in your home directory. You just select the library version you want to use to build your project. If you build your project against the Qt librairies installed in your home directory, you can still release your application you include a copy of every required so file within the application directory. Don't forget to distribute your application with the platform directory (I don't remember where it is). Frederic -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3847460.s6yi7ti...@fmarchal.edpnet.be
