[gentoo-dev] revbumping ebuilds after USE dependency changes

[gentoo-dev] revbumping ebuilds after USE dependency changes

[Alex Alexander]

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

Hello,

Please revbump an ebuild after changing its USE dependencies.

Using net-p2p/transmission as an example, it used to depend on 
	dev-qt/qtgui:4=[dbus]
however, qtgui lost the dbus useflag, so the dependency was changed to
	dev-qt/qtgui:4=[dbus(+)]
without revbumping the transmission ebuild. [0]

Portage fails to notice this when resolving dependencies if the package was
installed prior to the change, resulting in errors like the following:
  (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts
		with dev-qt/qtgui:4/4=[dbus] required by
			(net-p2p/transmission-2.80::gentoo, installed)

which, I imagine, could be very frustrating for a user who doesn't mess
with the internals of Gentoo often.

You might think that such a revbump is overkill, but in reality the user will
have to re-emerge the package anyway in order to get rid of the error, so there
is no point in avoiding it, unless portage changes the way it handles these
changes.

[0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2

Thanks,
-- 
Alex Alexander | wired@gentoo
+ www.linuxized.com
++ www.leetworks.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] revbumping ebuilds after USE dependency changes

[Mike Gilbert]

On Wed, Jul 24, 2013 at 8:49 AM, Alex Alexander <wired@gentoo.org> wrote:
> Hello,
>
> Please revbump an ebuild after changing its USE dependencies.
>
> Using net-p2p/transmission as an example, it used to depend on
>         dev-qt/qtgui:4=[dbus]
> however, qtgui lost the dbus useflag, so the dependency was changed to
>         dev-qt/qtgui:4=[dbus(+)]
> without revbumping the transmission ebuild. [0]
>
> Portage fails to notice this when resolving dependencies if the package was
> installed prior to the change, resulting in errors like the following:
>   (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts
>                 with dev-qt/qtgui:4/4=[dbus] required by
>                         (net-p2p/transmission-2.80::gentoo, installed)
>
> which, I imagine, could be very frustrating for a user who doesn't mess
> with the internals of Gentoo often.
>
> You might think that such a revbump is overkill, but in reality the user will
> have to re-emerge the package anyway in order to get rid of the error, so there
> is no point in avoiding it, unless portage changes the way it handles these
> changes.
>
> [0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2
>

Actually, Portage normally handles this situation gracefully by using
the dependencies from the portage tree instead of vdb. However, in the
case of a slot-operator dep, it always uses vdb.

See bug 477544.

https://bugs.gentoo.org/show_bug.cgi?id=477544

Re: [gentoo-dev] revbumping ebuilds after USE dependency changes

[Alex Alexander]

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

On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote:
> On Wed, Jul 24, 2013 at 8:49 AM, Alex Alexander <wired@gentoo.org> wrote:
> > Hello,
> >
> > Please revbump an ebuild after changing its USE dependencies.
> >
> > Using net-p2p/transmission as an example, it used to depend on
> >         dev-qt/qtgui:4=[dbus]
> > however, qtgui lost the dbus useflag, so the dependency was changed to
> >         dev-qt/qtgui:4=[dbus(+)]
> > without revbumping the transmission ebuild. [0]
> >
> > Portage fails to notice this when resolving dependencies if the package was
> > installed prior to the change, resulting in errors like the following:
> >   (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts
> >                 with dev-qt/qtgui:4/4=[dbus] required by
> >                         (net-p2p/transmission-2.80::gentoo, installed)
> >
> > which, I imagine, could be very frustrating for a user who doesn't mess
> > with the internals of Gentoo often.
> >
> > You might think that such a revbump is overkill, but in reality the user will
> > have to re-emerge the package anyway in order to get rid of the error, so there
> > is no point in avoiding it, unless portage changes the way it handles these
> > changes.
> >
> > [0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2
> >
> 
> Actually, Portage normally handles this situation gracefully by using
> the dependencies from the portage tree instead of vdb. However, in the
> case of a slot-operator dep, it always uses vdb.
> 
> See bug 477544.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=477544

Aha, thanks for the bug, missed it. Well, my recommendation is still
valid until portage gets fixed. Glad to know someone's looking into
it though.

-- 
Alex Alexander | wired@gentoo
+ www.linuxized.com
++ www.leetworks.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] revbumping ebuilds after USE dependency changes

["Paweł Hajdan, Jr."]

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

On 7/24/13 8:31 AM, Alex Alexander wrote:
> On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote:
>> Actually, Portage normally handles this situation gracefully by using
>> the dependencies from the portage tree instead of vdb. However, in the
>> case of a slot-operator dep, it always uses vdb.
>>
>> See bug 477544.
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=477544
> 
> Aha, thanks for the bug, missed it. Well, my recommendation is still
> valid until portage gets fixed. Glad to know someone's looking into
> it though.

Can we get that recommendation to the devmanual possibly?

I'm still a little bit confused what exactly would warrant such a
revision bump, and why.

Paweł



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

Re: [gentoo-dev] revbumping ebuilds after USE dependency changes

[Davide Pesavento]

On Wed, Jul 24, 2013 at 9:15 AM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Wed, Jul 24, 2013 at 8:49 AM, Alex Alexander <wired@gentoo.org> wrote:
>> Hello,
>>
>> Please revbump an ebuild after changing its USE dependencies.
>>
>> Using net-p2p/transmission as an example, it used to depend on
>>         dev-qt/qtgui:4=[dbus]
>> however, qtgui lost the dbus useflag, so the dependency was changed to
>>         dev-qt/qtgui:4=[dbus(+)]
>> without revbumping the transmission ebuild. [0]
>>
>> Portage fails to notice this when resolving dependencies if the package was
>> installed prior to the change, resulting in errors like the following:
>>   (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts
>>                 with dev-qt/qtgui:4/4=[dbus] required by
>>                         (net-p2p/transmission-2.80::gentoo, installed)
>>
>> which, I imagine, could be very frustrating for a user who doesn't mess
>> with the internals of Gentoo often.
>>
>> You might think that such a revbump is overkill, but in reality the user will
>> have to re-emerge the package anyway in order to get rid of the error, so there
>> is no point in avoiding it, unless portage changes the way it handles these
>> changes.
>>
>> [0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2
>>
>
> Actually, Portage normally handles this situation gracefully by using
> the dependencies from the portage tree instead of vdb. However, in the
> case of a slot-operator dep, it always uses vdb.
>
> See bug 477544.
>
> https://bugs.gentoo.org/show_bug.cgi?id=477544
>

Moreover, a slot operator dep on Qt libraries is pointless. Please
remove the '='.

Thanks,
Davide

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Michał Górny]

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

Dnia 2013-07-24, o godz. 13:23:15
Ryan Hill <dirtyepic@gentoo.org> napisał(a):

> On Wed, 24 Jul 2013 08:48:14 -0700
> ""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
> 
> > On 7/24/13 8:31 AM, Alex Alexander wrote:
> > > On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote:
> > >> Actually, Portage normally handles this situation gracefully by using
> > >> the dependencies from the portage tree instead of vdb. However, in the
> > >> case of a slot-operator dep, it always uses vdb.
> > >>
> > >> See bug 477544.
> > >>
> > >> https://bugs.gentoo.org/show_bug.cgi?id=477544
> > > 
> > > Aha, thanks for the bug, missed it. Well, my recommendation is still
> > > valid until portage gets fixed. Glad to know someone's looking into
> > > it though.
> > 
> > Can we get that recommendation to the devmanual possibly?
> > 
> > I'm still a little bit confused what exactly would warrant such a
> > revision bump, and why.
> 
> Revision bumps are necessary when there are changes made to the files that are
> installed by a package.  That's it.
> 
> When bumping to EAPI 5 it is recommended to do a rev bump so this sub-slot
> business can be recorded in the vdb.
> 
> Are there any others that aren't personal opinion?
> 
> Course you can do a rev bump for whatever reason you want, but some people will
> frown on it unless you have a good reason.  eg. if you revbump a stable ebuild
> for a build fix i will spend some time sighing at my screen.

Actually per PMS you are required to revbump (and therefore require
upgrade on users' side) whenever you change the deps and don't expect
to add a new version soon enough. Otherwise your changes don't get
spread and users end up with never-ending blockers and stuff like that.

Other thing is that Portage explicitly ignores PMS in this matter
and uses dependencies from ebuilds rather than recorded ones. This is
supposedly wrong, supposedly slow but allows us to be lazy.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Ciaran McCreesh]

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

On Wed, 24 Jul 2013 21:17:26 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> Other thing is that Portage explicitly ignores PMS in this matter
> and uses dependencies from ebuilds rather than recorded ones. This is
> supposedly wrong, supposedly slow but allows us to be lazy.

It's not slow. It's just wrong, and intermittently leads to very
strange behaviour.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Ryan Hill]

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

On Wed, 24 Jul 2013 08:48:14 -0700
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> On 7/24/13 8:31 AM, Alex Alexander wrote:
> > On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote:
> >> Actually, Portage normally handles this situation gracefully by using
> >> the dependencies from the portage tree instead of vdb. However, in the
> >> case of a slot-operator dep, it always uses vdb.
> >>
> >> See bug 477544.
> >>
> >> https://bugs.gentoo.org/show_bug.cgi?id=477544
> > 
> > Aha, thanks for the bug, missed it. Well, my recommendation is still
> > valid until portage gets fixed. Glad to know someone's looking into
> > it though.
> 
> Can we get that recommendation to the devmanual possibly?
> 
> I'm still a little bit confused what exactly would warrant such a
> revision bump, and why.

Revision bumps are necessary when there are changes made to the files that are
installed by a package.  That's it.

When bumping to EAPI 5 it is recommended to do a rev bump so this sub-slot
business can be recorded in the vdb.

Are there any others that aren't personal opinion?

Course you can do a rev bump for whatever reason you want, but some people will
frown on it unless you have a good reason.  eg. if you revbump a stable ebuild
for a build fix i will spend some time sighing at my screen.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Ryan Hill]

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

On Wed, 24 Jul 2013 21:17:26 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2013-07-24, o godz. 13:23:15
> Ryan Hill <dirtyepic@gentoo.org> napisał(a):
> 
> > On Wed, 24 Jul 2013 08:48:14 -0700
> > ""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
> > 
> > > On 7/24/13 8:31 AM, Alex Alexander wrote:
> > > > On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote:
> > > >> Actually, Portage normally handles this situation gracefully by using
> > > >> the dependencies from the portage tree instead of vdb. However, in the
> > > >> case of a slot-operator dep, it always uses vdb.
> > > >>
> > > >> See bug 477544.
> > > >>
> > > >> https://bugs.gentoo.org/show_bug.cgi?id=477544
> > > > 
> > > > Aha, thanks for the bug, missed it. Well, my recommendation is still
> > > > valid until portage gets fixed. Glad to know someone's looking into
> > > > it though.
> > > 
> > > Can we get that recommendation to the devmanual possibly?
> > > 
> > > I'm still a little bit confused what exactly would warrant such a
> > > revision bump, and why.
> > 
> > Revision bumps are necessary when there are changes made to the files that
> > are installed by a package.  That's it.
> > 
> > When bumping to EAPI 5 it is recommended to do a rev bump so this sub-slot
> > business can be recorded in the vdb.
> > 
> > Are there any others that aren't personal opinion?
> > 
> > Course you can do a rev bump for whatever reason you want, but some people
> > will frown on it unless you have a good reason.  eg. if you revbump a
> > stable ebuild for a build fix i will spend some time sighing at my screen.
> 
> Actually per PMS you are required to revbump (and therefore require
> upgrade on users' side) whenever you change the deps and don't expect
> to add a new version soon enough. Otherwise your changes don't get
> spread and users end up with never-ending blockers and stuff like that.
> 
> Other thing is that Portage explicitly ignores PMS in this matter
> and uses dependencies from ebuilds rather than recorded ones. This is
> supposedly wrong, supposedly slow but allows us to be lazy.

Thank god.  That is insane.

Let's not document that one in the manual.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Ciaran McCreesh]

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

On Wed, 24 Jul 2013 13:40:48 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> > Actually per PMS you are required to revbump (and therefore require
> > upgrade on users' side) whenever you change the deps and don't
> > expect to add a new version soon enough. Otherwise your changes
> > don't get spread and users end up with never-ending blockers and
> > stuff like that.
> > 
> > Other thing is that Portage explicitly ignores PMS in this matter
> > and uses dependencies from ebuilds rather than recorded ones. This
> > is supposedly wrong, supposedly slow but allows us to be lazy.
> 
> Thank god.  That is insane.
> 
> Let's not document that one in the manual.

The issue's not as simple as one might initially think, and both ways
have their drawbacks.

The only drawback of "use dependencies at the time the package was
installed" is that developers can't retroactively change dependencies
without a revbump.

The drawbacks of "use VDB" are:

* That ebuilds can be updated without revbumps to have "changed"
  dependencies. The example that comes up most is pkg_prerm changes to
  use or stop using a foo-config type app. If a package mangler then
  uses the "changed" dependencies, it can lead to premature
  uninstallation of a foo-config that's needed to safely uninstall
  something.

* That it assumes there's a one-to-one correspondence between
  "installed ebuild" and "installable ebuild". This means that whenever
  ebuild versions are cleaned up in the tree, suddenly the dependencies
  of your installed packages change. It gets even trickier when
  overlays and binaries are involved.

* The way Portage does it doesn't work if there are := dependencies.

So the tradeoff is between "require more revbumps" or "randomly broken
dependency handling", and neither is ideal. Portage currently leans
towards the latter, on the grounds that users expect broken
dependencies and strange failures every now and again, but hate
"wasting time" on "unnecessary" revbumps.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/24/2013 03:18 PM, Ciaran McCreesh wrote:
> On Wed, 24 Jul 2013 21:17:26 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>> Other thing is that Portage explicitly ignores PMS in this matter
>> and uses dependencies from ebuilds rather than recorded ones. This is
>> supposedly wrong, supposedly slow but allows us to be lazy.
> 
> It's not slow. It's just wrong, and intermittently leads to very
> strange behaviour.
> 
++
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR8HcOAAoJEKXdFCfdEflKsT4P/iU2JsDexTxUZ2IJzfTmXG80
1j1RL8fnisQ9Jq83xHE45yUpQzMYbvWqSCayu56WRzmwYmGQgRvysCg749HI3KVV
lWRxrY28psGoXplwJf0VKUhBTXo6sp6Yb9Xnhgd2nHg5aPTb9SFYpfg8wnreUXuo
OnQ7/EVN+9ZwVqWABRPIrSX9k1byexKRz1JdkNyWyuTDwwQw6GUHIjWet5uvy0tC
Wd8NZ8Ow5JA3HB5rfolTdl4fYTKCLMqwVkqOTOr37lBSx4gzu8w9hPAy5SenWcMl
wbbB8uKktdcSUE46UHPuxM21D+mYjMP+YzU2MecZVe5pUoHaCvmVBCpDrXf68/Jt
wRbZRn5F3I8WJUQe82xR1VRjmwbmMx+mqvdJlQO3VSEF7EcXZiYKt6EyLfz869e+
57EvlwktW1yh/x4WIJeYfU+KJHKDLMJCbUxn4mmcZBowY0Qiif8vzGhT4r5kdDqo
1ewLImqvgE5o7zzNiPFx2M43ikbWwnU4KCm4nTi5rYdB5+y4D2FzXZyCz/UBGmYZ
JvuRteriNwUcF2rW8Mzw2+SP2wxcxyC/8CbJOC2Df8qj/XOWkY9N/0u6Mrj4NmXs
OD1Ner2fXfed2xybbC8QIuRQlduspBR+lHU08AYbWH46Q3tbhS7HPdcGF6IO3EPb
Dnb8zJNZK5cXe0FanC3a
=wstY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

["Paweł Hajdan, Jr."]

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

On 7/24/13 5:53 PM, Rick "Zero_Chaos" Farina wrote:
> On 07/24/2013 03:18 PM, Ciaran McCreesh wrote:
>> On Wed, 24 Jul 2013 21:17:26 +0200
>> Michał Górny <mgorny@gentoo.org> wrote:
>>> Other thing is that Portage explicitly ignores PMS in this matter
>>> and uses dependencies from ebuilds rather than recorded ones. This is
>>> supposedly wrong, supposedly slow but allows us to be lazy.
> 
>> It's not slow. It's just wrong, and intermittently leads to very
>> strange behaviour.
> 
> ++

Shall we revisit that, and try to make portage behave more correctly,
even if it means more revbumps / rebuilding?

Paweł


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

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Zac Medico]

On Wed, Jul 24, 2013 at 8:50 PM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> On 7/24/13 5:53 PM, Rick "Zero_Chaos" Farina wrote:
>> On 07/24/2013 03:18 PM, Ciaran McCreesh wrote:
>>> On Wed, 24 Jul 2013 21:17:26 +0200
>>> Michał Górny <mgorny@gentoo.org> wrote:
>>>> Other thing is that Portage explicitly ignores PMS in this matter
>>>> and uses dependencies from ebuilds rather than recorded ones. This is
>>>> supposedly wrong, supposedly slow but allows us to be lazy.
>>
>>> It's not slow. It's just wrong, and intermittently leads to very
>>> strange behaviour.
>>
>> ++
>
> Shall we revisit that, and try to make portage behave more correctly,
> even if it means more revbumps / rebuilding?

Just set EMERGE_DEFAULT_DEPS="--dynamic-deps=n" in make.conf if you'd
like to test it.

[gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Michael Palimaka]

On 25/07/2013 05:17, Michał Górny wrote:
> Actually per PMS you are required to revbump (and therefore require
> upgrade on users' side) whenever you change the deps and don't expect
> to add a new version soon enough.

Can you please provide a link/reference to that part? I am interested in 
reading more about it.

Re: [gentoo-dev] revbumping ebuilds after USE dependency changes

[Dale]

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

Alex Alexander wrote:
> Hello,
>
> Please revbump an ebuild after changing its USE dependencies.
>
> Using net-p2p/transmission as an example, it used to depend on
>     dev-qt/qtgui:4=[dbus]
> however, qtgui lost the dbus useflag, so the dependency was changed to
>     dev-qt/qtgui:4=[dbus(+)]
> without revbumping the transmission ebuild. [0]
>
> Portage fails to notice this when resolving dependencies if the
package was
> installed prior to the change, resulting in errors like the following:
>   (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts
>         with dev-qt/qtgui:4/4=[dbus] required by
>             (net-p2p/transmission-2.80::gentoo, installed)
>
> which, I imagine, could be very frustrating for a user who doesn't mess
> with the internals of Gentoo often.
>
> You might think that such a revbump is overkill, but in reality the
user will
> have to re-emerge the package anyway in order to get rid of the error,
so there
> is no point in avoiding it, unless portage changes the way it handles
these
> changes.
>
> [0]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2
>
> Thanks,

As a lowly user, I have been banging on this for a few days now.  I'm
almost bald from all the hair pulling.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


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

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> Shall we revisit that, and try to make portage behave more correctly,
>> even if it means more revbumps / rebuilding?
> 
> Just set EMERGE_DEFAULT_DEPS="--dynamic-deps=n" in make.conf if you'd
> like to test it.
> 
> 
What (if anything) does that break or slow down?  I've had all kinds of
recent issues with updates breaking my autobuilds due to these issues.

Thanks,
Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR8URsAAoJEKXdFCfdEflKftIP/0w86aBoN8bO5WbJ3VAs4Q1L
n50uLzcmo+mvU/1suL8oI8KEjUyIKHO6pItkJICwnb3BWzrrI0KJVf6xfkevd48e
3sQE6c16hzxiU/fEghMiJ2tq8IcC+n/iIZ817Mo3OLw9hV5Fo3duj5JGM3MyQceW
cUI1VlIgCm0z6a4TqmwAUXfyTBbYXVLfJF+MyRPIR2PcOGYtFNQ9O7CK0nET5TVw
f4eTViXjOGs2EMHDLbkUvmeNZgfmqDbQojWqPFjmu6Zot4VemvF2D5PjjBdd1Lt6
wKC6ZDxTVZp020haHrY+eu2ly6Ue6rno8rePhNmtM6sdW2hXyyE1OdB+dPKoaCwZ
2GfD//6r2J1BKk4QMGeSapH9xj5N4rDaz71N9lYtW1wkRErgLgbYeix4cFduaU4M
L0nHmDrIDffmUBkK8c1igcsas5s9VAub4tYPerCsXF5re8W6zojt5a9OVYqwFjem
8KEyJ/OH7oAstyCgyRoLECLvrjfJejEM3iO1FHcjnkXBhG29OK8eLK8Ao+cF5int
Qxu7xHPcL/ekr5caI7ONAWTgjv5mkLtr2aO/TP/EhnLyIk58ROfogpSit034BnZp
wVwGdUAPuJG5ATv8MWNfW8ukQcNkdSfbxgxiSe72MVjzUy2Pd5kEpzrGZArW1obM
ATULUhIeHMe8lLaVfEpg
=BMh2
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Zac Medico]

On 07/25/2013 08:29 AM, Rick "Zero_Chaos" Farina wrote:
>>> Shall we revisit that, and try to make portage behave more correctly,
>>> even if it means more revbumps / rebuilding?
> 
>> Just set EMERGE_DEFAULT_DEPS="--dynamic-deps=n" in make.conf if you'd
>> like to test it.
> 
> 
> What (if anything) does that break or slow down?  I've had all kinds of
> recent issues with updates breaking my autobuilds due to these issues.

If you use --dynamic-deps=n then you are likely to experience more
dependency conflicts (or unsatisfied deps) triggered by installed
packages that have since had their dependencies changed without a
revision bump. These dependency conflicts are like the ones that you've
experienced with binary packages [1], but they will apply to installed
packages instead of binary packgaes.

[1] https://bugs.gentoo.org/show_bug.cgi?id=282927
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/25/2013 01:28 PM, Zac Medico wrote:
> On 07/25/2013 08:29 AM, Rick "Zero_Chaos" Farina wrote:
>>>> Shall we revisit that, and try to make portage behave more correctly,
>>>> even if it means more revbumps / rebuilding?
>>
>>> Just set EMERGE_DEFAULT_DEPS="--dynamic-deps=n" in make.conf if you'd
>>> like to test it.
>>
>>
>> What (if anything) does that break or slow down?  I've had all kinds of
>> recent issues with updates breaking my autobuilds due to these issues.
> 
> If you use --dynamic-deps=n then you are likely to experience more
> dependency conflicts (or unsatisfied deps) triggered by installed
> packages that have since had their dependencies changed without a
> revision bump. These dependency conflicts are like the ones that you've
> experienced with binary packages [1], but they will apply to installed
> packages instead of binary packgaes.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=282927
> 

So I replace one set of dependency errors with another?  This doesn't
seem all that useful...

Perhaps we need to reevaluate how we handle these things.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR8W56AAoJEKXdFCfdEflK1oMP/39a2my+nZ0rLkp3kgkWiPAT
eWT9q9SABvbyc7S93zAF+YVqTzma3a9B+EpqOiujmggF5QgioMWlfpIpPLgdo5TX
hoj7UfHncCZS+B8jprFbptJy6E63N020hUATH45RO0yCO+yzd4n1T+Lub7qiZ9jU
NbETsndPbXC0i7HWJ4xUK00B8P1FFFVtJBVTVq050L/OKKz+t6xC6zw/vmFubs65
vPO0oHPWJuyfPQb25zD0+LO+3YUbjkI5caUuNInxIXxI15azIyUX2V5Cbd5e4Cq6
6TH2PSTcugo34IukWKJqQYRm4JO095HvukIK40taS7c4I50ToTVMyNjXn8h/FqKH
s+IG2amnwdW2MiJT/PhFAyB++QUfxo3i5OVnhezJea1SYkI6rrBjbdef+Hgl1b5R
MEPNBuJlteWcn+51JD17dbdJK7i9BZlPo7jDV/OxWymtLtHduiFzkf/z/lffKqqx
0dX2d0mX1pFvnSzVHeN9loOc9vek/yq/P3Utwn4gS9X8VnY0I9ytKUC+Djud5/OB
C6o7+xilk7RH3JTHezgUit2jtL0YyPOHkhJ5T2eL9P8YigH/vz2nmmKlPY6OK6c4
Tu/EzPvisuaBTLOWvW5kpBDR0jv4iKRiS6JzcZchEqHuX6u7vjInP8MavZPsGlLC
QbUSEcKWSf4vJXTf3h0y
=le9R
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Zac Medico]

On 07/25/2013 11:29 AM, Rick "Zero_Chaos" Farina wrote:
> On 07/25/2013 01:28 PM, Zac Medico wrote:
>> On 07/25/2013 08:29 AM, Rick "Zero_Chaos" Farina wrote:
>>>>> Shall we revisit that, and try to make portage behave more correctly,
>>>>> even if it means more revbumps / rebuilding?
>>>
>>>> Just set EMERGE_DEFAULT_DEPS="--dynamic-deps=n" in make.conf if you'd
>>>> like to test it.
>>>
>>>
>>> What (if anything) does that break or slow down?  I've had all kinds of
>>> recent issues with updates breaking my autobuilds due to these issues.
> 
>> If you use --dynamic-deps=n then you are likely to experience more
>> dependency conflicts (or unsatisfied deps) triggered by installed
>> packages that have since had their dependencies changed without a
>> revision bump. These dependency conflicts are like the ones that you've
>> experienced with binary packages [1], but they will apply to installed
>> packages instead of binary packgaes.
> 
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=282927
> 
> 
> So I replace one set of dependency errors with another?  This doesn't
> seem all that useful...
> 
> Perhaps we need to reevaluate how we handle these things.

The advantage of using --dynamic-deps=n is that it triggers dependencies
conflicts that otherwise go unnoticed, prompting you to do a revision
bump in order to trigger rebuilds for people who have already
build/installed the older version that now has obsolete deps.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Michał Górny]

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

Dnia 2013-07-25, o godz. 17:07:00
Michael Palimaka <kensington@gentoo.org> napisał(a):

> On 25/07/2013 05:17, Michał Górny wrote:
> > Actually per PMS you are required to revbump (and therefore require
> > upgrade on users' side) whenever you change the deps and don't expect
> > to add a new version soon enough.
> 
> Can you please provide a link/reference to that part? I am interested in 
> reading more about it.

To be honest, I have no idea if that's worded at all since PMS doesn't
cover vardb. I may have overused the term 'per PMS' then.

However, this is what Brian & Ciaran (at least) were criticizing for
some time. The idea is that when you build an ebuild, you are basically
either creating a binary package or installing a package to the system
(or both). Along with that, metadata is transferred from the ebuild to
the package or vardb.

With a proper design, you have two 'repos': one with ebuilds,
and the other consisting purely of installed packages (vardb/system).
What's important, per definition vardb is self-satisfactory. That is,
dependencies of every installed package are supposed to be satisfied by
installed packages purely.

Now, what portage does is implicitly applying _some_ of the metadata
from the ebuild tree to vardb without rebuilding the package. In some
cases. As an effect, vardb is no longer self-satisfactory,
and represents something between the package that was built
and the current ebuild.

Ciaran has already elaborated a bit on the potential issues. It gets
most dangerous when you create some meaningful changes without
a revbump. I'll give you a simple example that I can think of.

Say, you fix a semi-build-time issue of linking against unnecessary
dep. Users who build the ebuild from now on benefit by having less
deps. The dep is less problematic than rebuilding the package, so users
who built it before prefer to wait for next version.

But in this case, portage may implicitly update the deps from ebuild
without rebuilding it. This means that users who still link against
the dep, may end up with the dep removed and program broken.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Kent Fredric]

On 28 July 2013 21:11, Michał Górny <mgorny@gentoo.org> wrote:
> Now, what portage does is implicitly applying _some_ of the metadata
> from the ebuild tree to vardb without rebuilding the package. In some
> cases. As an effect, vardb is no longer self-satisfactory,
> and represents something between the package that was built
> and the current ebuild.
>
> Ciaran has already elaborated a bit on the potential issues. It gets
> most dangerous when you create some meaningful changes without
> a revbump. I'll give you a simple example that I can think of.
>
> Say, you fix a semi-build-time issue of linking against unnecessary
> dep. Users who build the ebuild from now on benefit by having less
> deps. The dep is less problematic than rebuilding the package, so users
> who built it before prefer to wait for next version.
>
> But in this case, portage may implicitly update the deps from ebuild
> without rebuilding it. This means that users who still link against
> the dep, may end up with the dep removed and program broken.


If there was a portage feature of some kind that triggered a rebuild
when /var/db/* deps mismatched ebuild deps, I'd use that ( similar to
how you can trigger a rebuild when USE changes )

I'm one of those people who doesn't mind installing the same thing a
million times a week =)

-- 
Kent

[gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Duncan]

Michał Górny posted on Sun, 28 Jul 2013 11:11:13 +0200 as excerpted:

> With a proper design, you have two 'repos': one with ebuilds,
> and the other consisting purely of installed packages (vardb/system).
> What's important, per definition vardb is self-satisfactory. That is,
> dependencies of every installed package are supposed to be satisfied by
> installed packages purely.
> 
> Now, what portage does is implicitly applying _some_ of the metadata
> from the ebuild tree to vardb without rebuilding the package. In some
> cases. As an effect, vardb is no longer self-satisfactory,
> and represents something between the package that was built and the
> current ebuild.
> 
> Ciaran has already elaborated a bit on the potential issues. It gets
> most dangerous when you create some meaningful changes without a
> revbump. I'll give you a simple example that I can think of.
> 
> Say, you fix a semi-build-time issue of linking against unnecessary dep.
> Users who build the ebuild from now on benefit by having less deps. The
> dep is less problematic than rebuilding the package, so users who built
> it before prefer to wait for next version.
> 
> But in this case, portage may implicitly update the deps from ebuild
> without rebuilding it. This means that users who still link against the
> dep, may end up with the dep removed and program broken.

This is an extremely good explanation (much better and shorter than I 
would/could have done, I believe).  Thanks.

The one thing it's missing, and that's more on the practical than 
theoretical end I believe the explanation was targeting, is that these 
days, portage's depclean has an additional level of caution/safety built-
in, that in practice limits the damage quite a bit from what the above 
theory would predict, very likely in response to complaints about that 
very problem.

I haven't checked the details and depclean does run far faster than 
revdep-rebuild so whatever it's doing isn't as thorough, but depclean now 
does at least some actual on-system checking before removing a package, 
and will refuse to remove a package it otherwise would (no database deps 
requiring it so the database says it's fine to remove) with an 
explanation of what's actually linked against it, if depclean's pre-clean 
scans indicate that removing the package would otherwise leave an 
unsatisfied/dangling linkage, asking you to rebuild the depending package 
first to remove that in-practice-but-not-in-database dependency.

This behavior can actually be a bit frustrating if the depending package 
in question has an "automagic" dependency that will link against a 
package if it finds it installed, but doesn't declare it as a dep, as the 
requested rebuild won't solve the undeclared dependency in that case, so 
the depended package must be removed manually (using emerge --unmerge, 
which doesn't do this scan and has a nice scary warning to that effect) 
and the automagic-depending package rebuilt AFTER the depended package as 
been removed.

That's actually how I ended up finding out how well depclean's scans 
work, since it said to rebuild a package that didn't declare a 
dependency, which I did, but that didn't solve the problem as it was an 
automagic dependency that was linked in as long as the files were found 
on the system to link against.  The gentoo automagic-dependency bug I 
filed was initially closed as invalid, too, because the gentoo package 
maintaining dev wasn't in fact aware of depclean's then rather new 
ability to catch such problems, either.  But I reopened, mentioning 
depclean's (then) new scanning and asking him to actually try it and to 
consult with Zac if he had questions about the (then) new behavior, which 
he evidently did, as the bug was fixed properly, automagic dependency 
converted into a USE flag covered dependency, with a comment to the bug 
thanking me for re-opening and alerting him to the problem. =:^)

Altho I believe it's limited to elf-dependency checking and arguably 
isn't the best theoretical solution, in practice depclean's solution is 
rather nice, since it catches both dynamic-dep problems like those in 
this thread, and automagic-linking issues that no pure database solution 
could catch, since by definition, automagic dependencies are not declared 
in the database, or they'd be declared dependencies not automagic 
dependencies.  (By the same token, it should catch dependencies for 
independently compiled and installed packages that are obviously not in 
the database except possibly via package.provided, as well. =:^)

But I do believe depclean's scan won't catch python/perl/ruby/shell/etc 
dependencies, only elf-binary.  That remains a problem, but one that for 
many gentooers anyway, isn't actually too big a deal in practice.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Zac Medico]

On 07/28/2013 05:39 PM, Duncan wrote:
> I haven't checked the details and depclean does run far faster than 
> revdep-rebuild so whatever it's doing isn't as thorough, but depclean now 
> does at least some actual on-system checking before removing a package, 
> and will refuse to remove a package it otherwise would (no database deps 
> requiring it so the database says it's fine to remove) with an 
> explanation of what's actually linked against it, if depclean's pre-clean 
> scans indicate that removing the package would otherwise leave an 
> unsatisfied/dangling linkage, asking you to rebuild the depending package 
> first to remove that in-practice-but-not-in-database dependency.

This behavior is controlled by the --depclean-lib-check option and also
interacts with FEATURES=preserve-libs. I suspect that the majority of
people have FEATURES=preserve-libs enabled these days, and for them the
behavior is for depclean to remove the packages but preserve their
libraries as needed (it's documented in the --depclean-lib-check section
of the emerge man page).
-- 
Thanks,
Zac

[gentoo-dev] Re: revbumping ebuilds after USE dependency changes

[Duncan]

Zac Medico posted on Mon, 29 Jul 2013 01:04:09 -0700 as excerpted:

> On 07/28/2013 05:39 PM, Duncan wrote:
>> [D]epclean now does [an elf-based dynamic deps scan] and will refuse to
>> remove a package [if that turns up a dependency], asking you to
>> rebuild the depending package first to remove that in-practice-but-
>> not-in-database dependency.
> 
> This behavior is controlled by the --depclean-lib-check option and also
> interacts with FEATURES=preserve-libs. I suspect that the majority of
> people have FEATURES=preserve-libs enabled these days, and for them the
> behavior is for depclean to remove the packages but preserve their
> libraries as needed (it's documented in the --depclean-lib-check section
> of the emerge man page).

FEATURE=-preserve-libs[1] here explains why I wasn't aware of that bit.  
But I guess I hadn't read the manpage in detail lately as I wasn't aware 
of the --depclean-lib-check parameter, either.

As always, thanks, both for the clarification and for your great work on 
portage, which is certainly one of the most directly experienced parts of 
gentoo for most users.  It's a relatively good part too, thanks to you 
and the others that have put so much work into portage. =:^)

---
[1] FEATURES=-preserve-libs: I prefer to find and fix right away the 
problems preserve-libs is intended to hide and thus religiously run both 
emerge --depclean and revdep-rebuild as the last bits of every update, so 
all preserve-libs does for me is get in the way of the proper functioning 
of revdep-rebuild.  I do appreciate the preemptive nature of EAPI-5's 
subslots, tho, and between that and --as-needed in LDFLAGS, revdep-
rebuild doesn't find much to rebuild these days.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman