[gentoo-user] Changing dependencies without upping version ??

[gentoo-user] Changing dependencies without upping version ??

[Ian Zimmerman]

I think this is the first time a package tried to play this trick on me:

--- /var/db/pkg/dev-libs/qcustomplot-1.3.2/qcustomplot-1.3.2.ebuild	2017-05-21 13:38:15.482740587 -0700
+++ /usr/portage/dev-libs/qcustomplot/qcustomplot-1.3.2.ebuild	2017-09-22 19:27:30.000000000 -0700
@@ -1,4 +1,4 @@
-# Copyright 1999-2016 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=6
@@ -14,19 +14,13 @@
 SLOT="0"
 LICENSE="GPL-3"
 KEYWORDS="amd64 ~arm x86 ~amd64-linux ~x86-linux"
-IUSE="qt5"
+IUSE=""
 
 RDEPEND="
-	!qt5? (
-		dev-qt/qtcore:4
-		dev-qt/qtgui:4
-	)
-	qt5? (
-		dev-qt/qtcore:5
-		dev-qt/qtgui:5
-		dev-qt/qtprintsupport:5
-		dev-qt/qtwidgets:5
-	)
+	dev-qt/qtcore:5
+	dev-qt/qtgui:5
+	dev-qt/qtprintsupport:5
+	dev-qt/qtwidgets:5
 "
 DEPEND="${RDEPEND}"
 
@@ -42,7 +36,7 @@
 }
 
 src_configure() {
-	use qt5 && eqmake5 || eqmake4
+	eqmake5
 }
 
 src_install() {


Is this an officially approved technique??  it is DIRTY.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Re: [gentoo-user] Changing dependencies without upping version ??

[John Blinka]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

>
>
> Is this an officially approved technique??  it is DIRTY.


I imagine that it is sanctioned, otherwise why would there be a
--changed-deps flag to emerge?  Does seem dirty.  Glad you asked the
question.  Would love to learn why this is allowed.  In my experience, it
happens quite often.

John Blinka

>

[-- Attachment #2: Type: text/html, Size: 709 bytes --]

Re: [gentoo-user] Changing dependencies without upping version ??

[Rich Freeman]

On Sun, Sep 24, 2017 at 2:51 PM, John Blinka <john.blinka@gmail.com> wrote:
>
>> Is this an officially approved technique??  it is DIRTY.
>
> I imagine that it is sanctioned, otherwise why would there be a
> --changed-deps flag to emerge?  Does seem dirty.  Glad you asked the
> question.  Would love to learn why this is allowed.  In my experience, it
> happens quite often.

Is this recent experience in the main repository?  This is something
QA started cracking down on maybe a year ago.  It is definitely
problematic, because portage won't pull in the new dependency until
you re-install the package, which means the dependency could get
removed/etc.  I'd have to dig up the details around the policy - it
might be allowed in very limited circumstances (there could be reasons
to change a dep that won't actually break anything already installed).

I ended up putting --changed-deps in my update script because I'd
rather not deal with the bugs this can cause.

-- 
Rich

Re: [gentoo-user] Changing dependencies without upping version ??

[Andreas K. Huettel]

Am Montag, 25. September 2017, 02:33:13 CEST schrieb Rich Freeman:
> On Sun, Sep 24, 2017 at 2:51 PM, John Blinka <john.blinka@gmail.com> wrote:
> >> Is this an officially approved technique??  it is DIRTY.
> > 
> > I imagine that it is sanctioned, otherwise why would there be a
> > --changed-deps flag to emerge?  Does seem dirty.  Glad you asked the
> > question.  Would love to learn why this is allowed.  In my experience, it
> > happens quite often.
> 
> Is this recent experience in the main repository?  This is something
> QA started cracking down on maybe a year ago.  It is definitely
> problematic, because portage won't pull in the new dependency until
> you re-install the package, which means the dependency could get
> removed/etc.  I'd have to dig up the details around the policy - it
> might be allowed in very limited circumstances (there could be reasons
> to change a dep that won't actually break anything already installed).
> 
> I ended up putting --changed-deps in my update script because I'd
> rather not deal with the bugs this can cause.

I think the debate somewhere ended at "it's maintainer's call, weighing 
unnecessary rebuilds versus technical correctness".

Not sure how time-consuming a qcustomplot is.


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-user] Changing dependencies without upping version ??

[Paul Colquhoun]

On Monday, 25 September 2017 4:51:22 AM AEST John Blinka wrote:
> > Is this an officially approved technique??  it is DIRTY.
> 
> I imagine that it is sanctioned, otherwise why would there be a
> --changed-deps flag to emerge?  Does seem dirty.  Glad you asked the
> question.  Would love to learn why this is allowed.  In my experience, it
> happens quite often.


Well, --changed-deps is also there for when you change USE flags on your system 
to activate (or deactivate) software features.


-- 
Reverend Paul Colquhoun, ULC.     http://andor.dropbear.id.au/
  Asking for technical help in newsgroups?  Read this first:
     http://catb.org/~esr/faqs/smart-questions.html#intro

Re: [gentoo-user] Changing dependencies without upping version ??

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On Sun, 24 Sep 2017 10:37:53 -0700, Ian Zimmerman wrote:

> Is this an officially approved technique??  it is DIRTY.

If the change doesn't affect the installed code, it is encouraged to
avoid unnecessary rebuilding.

For example, a new version of LibreOffice or Chromium depends on libfoo,
but the dev doesn't notice and already has libfoo installed so it works
for him. You also have it installed so the upgrade works for you, then it
fails for me and I file a bug report. If the dev revbumped the ebuild,
you would have to spend a couple of hours rebuilding Chromium to get
exactly the same code you had before. By not revbumping it, he fixes the
problem for me without inconveniencing you.


-- 
Neil Bothwick

System halted - Press all keys at once to continue.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: Changing dependencies without upping version ??

[Ian Zimmerman]

On 2017-09-24 21:05, Neil Bothwick wrote:

> If the change doesn't affect the installed code, it is encouraged to
> avoid unnecessary rebuilding.
> 
> For example, a new version of LibreOffice or Chromium depends on
> libfoo, but the dev doesn't notice and already has libfoo installed so
> it works for him. You also have it installed so the upgrade works for
> you, then it fails for me and I file a bug report. If the dev
> revbumped the ebuild, you would have to spend a couple of hours
> rebuilding Chromium to get exactly the same code you had before. By
> not revbumping it, he fixes the problem for me without inconveniencing
> you.

I see, but of course in this case the effect would be exactly the
opposite - forcing me to rebuild the core qt packages and everything
that depends on them.  And if this was not a mistake, it must have been
clear that would happen.

It feels like a sneaky way to finally get the few remaining qt4 stragglers
out of the way.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[gentoo-user] Re: Changing dependencies without upping version ??

[Michael Palimaka]

On 09/25/2017 03:37 AM, Ian Zimmerman wrote:
> Is this an officially approved technique??  it is DIRTY.

I see a few complaints in this thread, but nobody so far has elaborated
on the problem they have with this change.

[gentoo-user] Re: Changing dependencies without upping version ??

[Ian Zimmerman]

On 2017-09-25 22:24, Michael Palimaka wrote:

> I see a few complaints in this thread, but nobody so far has
> elaborated on the problem they have with this change.

The problem is that if I want to complete the upgrade the way portage
suggests, I have to (newly) allow in and time-consumingly build _all_
the qt5 core libraries, since they depend on one another in nearly
circular fashion, and the updated qtcustomplot becomes the "camel's
nose".

I dealt with this by unmerging the few qt using apps I had installed and
finding alternatives for them.  Some of the alternatives are inferior,
but it beats this "eternal transition" qt stuff.  I'll make a prediction
but I don't expect anyone to bet: by the time all useful packages
migrate to qt5, the qt6 transition will already be in full swing.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[gentoo-user] Re: Changing dependencies without upping version ??

[Michael Palimaka]

On 09/26/2017 03:03 AM, Ian Zimmerman wrote:
> On 2017-09-25 22:24, Michael Palimaka wrote:
> 
>> I see a few complaints in this thread, but nobody so far has
>> elaborated on the problem they have with this change.
> 
> The problem is that if I want to complete the upgrade the way portage
> suggests, I have to (newly) allow in and time-consumingly build _all_
> the qt5 core libraries, since they depend on one another in nearly
> circular fashion, and the updated qtcustomplot becomes the "camel's
> nose".
> 
> I dealt with this by unmerging the few qt using apps I had installed and
> finding alternatives for them.  Some of the alternatives are inferior,
> but it beats this "eternal transition" qt stuff.  I'll make a prediction
> but I don't expect anyone to bet: by the time all useful packages
> migrate to qt5, the qt6 transition will already be in full swing.
> 

If the only argument is you don't want to upgrade, I'm afraid there's
not much we can do to help you.

The reality is that Qt 4 has not been maintained for over 2 years and is
starting to break in worse and worse ways. As we do not have the
resources to maintain a local fork, we have no choice but to follow
upstream's decision to kill it off.

[gentoo-user] Re: Changing dependencies without upping version ??

[Ian Zimmerman]

On 2017-09-26 22:01, Michael Palimaka wrote:

> If the only argument is you don't want to upgrade, I'm afraid there's
> not much we can do to help you.

You're right that I don't want to upgrade, and I have already explained
my workaround for that.  But that is _not_ what I'm complaining about in
this thread.  Rather, my complaint is that such a major change is hidden
in an ebuild edit with no version/revision bump, which means I cannot
use the normal means (ie. package.mask) to prevent it.  Before I decided
to drop Qt completely, I had to make a local package of qtcustomplot in
my own repo.

Surely there are other reasons against this kind of thing?  What if
someone reports a bug in the package?  Now you don't know from the
version/rev number if it's linked with Qt4 or Qt5.  Is that not
important?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[gentoo-user] Re: Changing dependencies without upping version ??

[Kai Krakow]

Am Tue, 26 Sep 2017 11:45:45 -0700
schrieb Ian Zimmerman <itz@very.loosely.org>:

> On 2017-09-26 22:01, Michael Palimaka wrote:
> 
> > If the only argument is you don't want to upgrade, I'm afraid
> > there's not much we can do to help you.  
> 
> You're right that I don't want to upgrade, and I have already
> explained my workaround for that.  But that is _not_ what I'm
> complaining about in this thread.  Rather, my complaint is that such
> a major change is hidden in an ebuild edit with no version/revision
> bump, which means I cannot use the normal means (ie. package.mask) to
> prevent it.  Before I decided to drop Qt completely, I had to make a
> local package of qtcustomplot in my own repo.

If you don't want (or cannot) upgrade, you have two options:

  1. Prepare to maintain your own overlay and deal with it

  2. Don't use a rolling release distribution


Personally, and since you seem to know enough to manage your own
overlay, I'd stick to #1.


> Surely there are other reasons against this kind of thing?  What if
> someone reports a bug in the package?  Now you don't know from the
> version/rev number if it's linked with Qt4 or Qt5.  Is that not
> important?

The problem seems to be that while the package can be built against
both qt4 and qt5, qt4 wasn't present at all.

A proper way I'm sure you could have arranged with, would have been to
introduce both useflags, then mask the qt4 useflag and mark it for
removal during the next version bump. That would have given you an easy
opportunity to properly react to the change, by either unmasking the
flag and pinning the version, or copy the ebuild from db/pkg to your
own overlay.

I don't know how Gentoo policy suggests but I'm pretty sure this is one
of the official ways to prevent exactly your problem.

In the long way, tho, due to qt4 breakage, the qt5 useflag had to be
introduced, and qt4 support had to be dropped. But maybe not in just
one single step without revbump.

The change causes rebuilds for most qt users anyways, as either you had
one of the flags enabled and that resulted in a useflag change thus
rebuild, or: None of the useflags was set, and then you were not
affected (which probably was the "short sighted" decision for doing it
without a revbump in the first place).


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Changing dependencies without upping version ??

[Ian Zimmerman]

On 2017-09-27 02:38, Kai Krakow wrote:

> If you don't want (or cannot) upgrade, you have two options:
> 
>   1. Prepare to maintain your own overlay and deal with it
> 
>   2. Don't use a rolling release distribution
> 
> Personally, and since you seem to know enough to manage your own
> overlay, I'd stick to #1.

I do so already, and in fact my initial workaround was to fork the
ebuild in my repo, pretty much like you recommend.

But I didn't know that this was the official way of stopping upgrades.
I thought package.mask was that, and I think that's what the Handbook
(or maybe some other part of the wiki) recommends.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[gentoo-user] Re: Changing dependencies without upping version ??

[Kai Krakow]

Am Tue, 26 Sep 2017 18:30:33 -0700
schrieb Ian Zimmerman <itz@very.loosely.org>:

> On 2017-09-27 02:38, Kai Krakow wrote:
> 
> > If you don't want (or cannot) upgrade, you have two options:
> > 
> >   1. Prepare to maintain your own overlay and deal with it
> > 
> >   2. Don't use a rolling release distribution
> > 
> > Personally, and since you seem to know enough to manage your own
> > overlay, I'd stick to #1.  
> 
> I do so already, and in fact my initial workaround was to fork the
> ebuild in my repo, pretty much like you recommend.
> 
> But I didn't know that this was the official way of stopping upgrades.
> I thought package.mask was that, and I think that's what the Handbook
> (or maybe some other part of the wiki) recommends.

Yes, masking of course. But at some point in time, the ebuild would be
dropped. And you may want to keep it around for rebuilds.


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: Changing dependencies without upping version ??

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

On Tue, 26 Sep 2017 18:30:33 -0700, Ian Zimmerman wrote:

> I do so already, and in fact my initial workaround was to fork the
> ebuild in my repo, pretty much like you recommend.
> 
> But I didn't know that this was the official way of stopping upgrades.
> I thought package.mask was that, and I think that's what the Handbook
> (or maybe some other part of the wiki) recommends.

This is Gentoo, "official" is a moving target. package.mask is good for
preventing upgrade to a specific version, but it can't be used to block
all updates on its own because eventually the older versions will be
treecleaned. That's why you need to keep them n a local overlay, and be
prepared to deal with any breakage they may introduce.


-- 
Neil Bothwick

This tagline is baroque; please call Bach.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]