Re: [gentoo-dev] don't rely on dynamic deps
On 7/21/14, 11:52 PM, Alexander Berntsen wrote: Michał has documented the shortcomings of dynamic deps in our wiki[0]. (Thank you!) This documentation also includes two of our possible solutions. [0] https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies Thank you, this is very useful. I didn't understand the issue much before reading that page. One question: why for Removal of a USE flag along with the relevant dependencies dynamic deps say revbump + unnecessary rebuild? What would happen without the revbump? 1. Improve dynamic-deps. This is, as Michał pointed out earlier in this thread a pipe dream. Agreed. 2. Remove dynamic-deps. This is what I think currently makes sense. +1 I also think it's the best option. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: don't rely on dynamic deps
Pacho Ramos pa...@gentoo.org wrote: Maybe this could be solved by having two kinds of revisions: - One would rebuild all as usually (for example, -r1...) - The other one would only regenerate VDB and wouldn't change the installed files (for example, -r1.1) I made the same suggestion already on the corresponding bug https://bugs.gentoo.org/show_bug.cgi?id=516612#c33 without any response. It seems to me that this could avoid the problem of useless recompilation and would allow fine-graining of the issue by the ebuild maintainer (if not the maintainer of the ebuild, who else should be able to decide whether recompilation might be necessary to handle certain exceptions?) and simultaneously allow to revbump even on presumably tiny dependency changes. I still have not seen an argument against this idea. Of course, this would need an EAPI bump and could only be used for packages which are (or switch to(?)) this new EAPI, so a few (core) packages which should stay EAPI=0 for a long time are excluded from this for still quite a while. But apart from that few exceptions...?
Re: [gentoo-dev] Re: don't rely on dynamic deps
El mar, 22-07-2014 a las 07:39 +, Martin Vaeth escribió: Pacho Ramos pa...@gentoo.org wrote: Maybe this could be solved by having two kinds of revisions: - One would rebuild all as usually (for example, -r1...) - The other one would only regenerate VDB and wouldn't change the installed files (for example, -r1.1) I made the same suggestion already on the corresponding bug https://bugs.gentoo.org/show_bug.cgi?id=516612#c33 without any response. Just CCed :) It seems to me that this could avoid the problem of useless recompilation and would allow fine-graining of the issue by the ebuild maintainer (if not the maintainer of the ebuild, who else should be able to decide whether recompilation might be necessary to handle certain exceptions?) and simultaneously allow to revbump even on presumably tiny dependency changes. I still have not seen an argument against this idea. Of course, this would need an EAPI bump and could only be used for packages which are (or switch to(?)) this new EAPI, so a few (core) packages which should stay EAPI=0 for a long time are excluded from this for still quite a while. But apart from that few exceptions...? Also, this could be a benefit in the long term if we need to spread any changes to VDB in the future.
[gentoo-dev] Re: don't rely on dynamic deps
On 07/22/2014 07:52 AM, Alexander Berntsen wrote: To sum up: My vote is disable dynamic-deps. And I would be happy to apply a patch that does this with the information I have today. What a great way to kill the distro. I can already heat my house with the number of unnecessary rebuilds - I can't imagine how many people will be left once we have to needlessly rebuild libreoffice and half the tree every time someone makes some minor change. If developers can't revbump correctly to address the shortcomings of dynamic deps, why do we expect they will be able to do so for static deps? When can we expect this issue to be brought before the Council? I look forward to seeing the specific examples of unavoidable breakage that would be required to make such a decision.
Re: [gentoo-dev] Re: don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/22/2014 10:21 AM, Michael Palimaka wrote: On 07/22/2014 07:52 AM, Alexander Berntsen wrote: To sum up: My vote is disable dynamic-deps. And I would be happy to apply a patch that does this with the information I have today. What a great way to kill the distro. I can already heat my house with the number of unnecessary rebuilds - I can't imagine how many people will be left once we have to needlessly rebuild libreoffice and half the tree every time someone makes some minor change. If developers can't revbump correctly to address the shortcomings of dynamic deps, why do we expect they will be able to do so for static deps? I find it somewhat curious that the difference between ~arch and stable hasn't been brought up in this discussion yet. IMHO a user on ~arch should expect a higher number of rebuilds, it _is_ after all testing, whereby at the point it reaches stable, the deps are hopefully more likely to be correct to begin with. Does anyone have any insight into where these changes most often occur? - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Ad astra per aspera To the stars through thorns -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTziGbAAoJEPw7F94F4Tag61QP/iznpmFoc2jKO1Ex8fHEFURA 8D6mgzmkBW2OYWux8JnSfmS7WBrXvs0869Ey/dTgQeMWsdaauhFSqGUTL8k2s3pD 2NZUiNM9fBDGrVR589r0EX5jpPoylsq+ViYc/GtsWfUx8QZGRQOs75ecIB3G5dfS eg15r/UI7Q5/vQv93s49Wl3EKWR8peqf46nsluXLMLZff80I6S2T0wGTZP9lMHd7 62Lwo4MxQEm+0XBqVNiY438qaF9eZBR8W14BPUwn2VWD0tL8CtNLiHZwLAAnYZrs FE4mgAFUQu+cmJow4DAPkOxMqiqFHLlyh2wVKkxNVTp4fwYdLLeQZWLVLqF3Z7BR cx75ocKCZmxcKqPA6gYj0hcl1W8uj7WyAwIOcYTzBBFf0eSaBzErtZ1WS7GVM/7z 1cauEo7DsDjiW2THZDkSy/zLn/O9XxRwMddqT7rT7IxDiy+V0n6AW4WD7mA/sAkd YfEnQmZARF0hK7msiy88ScBK73NpmAmU04kVoIV1IUaKNjaahWi4sk8MDKbV/V7z qnXvbQEejH9O9FbsY0ugWB6TL1imyfE3Va+Z63/nF3GFtO+XwJ3fqpT0VbDR3YBL sYXNQ9CHRBoemIOaCLLGPJbkwAALS2/gt9aVsxHLE75efvuGAqj2Qa9g8Paj5WBH Pq8eqnjDYOX02BBjSzSr =sYA4 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: don't rely on dynamic deps
On 22/07/14 11:21, Michael Palimaka wrote: On 07/22/2014 07:52 AM, Alexander Berntsen wrote: To sum up: My vote is disable dynamic-deps. And I would be happy to apply a patch that does this with the information I have today. What a great way to kill the distro. I can already heat my house with the number of unnecessary rebuilds - I can't imagine how many people will be left once we have to needlessly rebuild libreoffice and half the tree every time someone makes some minor change. If developers can't revbump correctly to address the shortcomings of dynamic deps, why do we expect they will be able to do so for static deps? When can we expect this issue to be brought before the Council? I look forward to seeing the specific examples of unavoidable breakage that would be required to make such a decision. +1
Re: [gentoo-dev] Re: don't rely on dynamic deps
El mar, 22-07-2014 a las 10:32 +0200, Kristian Fiskerstrand escribió: [...] I find it somewhat curious that the difference between ~arch and stable hasn't been brought up in this discussion yet. IMHO a user on ~arch should expect a higher number of rebuilds, it _is_ after all testing, whereby at the point it reaches stable, the deps are hopefully more likely to be correct to begin with. Does anyone have any insight into where these changes most often occur? Well, I have seen multiple times of this kind of fixes being noticed by people running really old stable boxes. They notice them when they update to latest stable and, then, we need to fix depends raising the versions usually :/ Maybe this discussion should be focused on trying to think about how to standardize a way for distinguish between revision bumps needing full rebuild or only VDB updates :|
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/07/14 02:36, hasufell wrote: William Hubbs: My concern about doing a revbump just because the deps change is that the new revision has to be committed in ~arch, so we then have to hit the arch teams, which we know are overworked anyway, with stable requests just because we changed the dependencies. Isn't that causing a lot of possibly unnecessary work for our arch teams? Procedure over logic? Just commit it straight to arch if repoman doesn't complain. William, this is, as Julian pointed out, a problem you can solve by changing your policies. This is not a problem related to the Portage software, in which dynamic-deps are broken. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPOMgYACgkQRtClrXBQc7VuuwD/UNQzX5aHSBbfXhyYRxH4oYzK N9aEf88WLVJK2JVKJBkA/iDF6ozQ9I0WKWpi/jvZa/W7yxKeZsXu5ACa5mbgM88+ =9/RG -END PGP SIGNATURE-
Re: [gentoo-dev] Re: don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/07/14 09:39, Martin Vaeth wrote: Pacho Ramos pa...@gentoo.org wrote: Maybe this could be solved by having two kinds of revisions: - One would rebuild all as usually (for example, -r1...) - The other one would only regenerate VDB and wouldn't change the installed files (for example, -r1.1) I made the same suggestion already on the corresponding bug https://bugs.gentoo.org/show_bug.cgi?id=516612#c33 without any response. Martin, I have no arguments against your idea to tell the PM that this bump only changes dependencies. My initial reaction is that this is a Good Thing. Would you like to try to implement it? - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPOM9wACgkQRtClrXBQc7WV1AD+LbojEp7TVY51WobwTflCPzQK wZbmGWiyyBhylG7AgWIBAJRKURylzKxjPWcmjGwllf2CXcublXZCmndzbHeoTm0B =doak -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
Alexander Berntsen: Julian, would you like to share your experiences with Paludis? My guess is that Paludis is more predictable in this respect. I.e., instead of breaking stuff, I expect Paludis to simply give up. Relying on dynamic deps as they are currently implemented simply causes the vdb to enter a broken state after some time. If you switch from portage to paludis then, you will encounter a lot of unsuitable candidates messages during dependency resolving and will have to figure out that the broken vdb is the reason. Afais paludis does not allow you to randomly break the vdb (or I haven't found the --nodeps option yet).
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21/07/14 05:06 PM, Pacho Ramos wrote:
El lun, 21-07-2014 a las 20:55 +0100, Ciaran McCreesh escribió:
On Mon, 21 Jul 2014 21:53:04 +0200 Andreas K. Huettel
dilfri...@gentoo.org wrote:
Revision must be bumped when the on-disk files installed by
the ebuild are changed. Nothing about dependencies.
This has been policy for a LONG time, and we're not going to
change it overnight just because you protest.
Policy used to be that you'd do a revbump when you wanted users
to reinstall stuff, and you wouldn't otherwise. The only
complication is that sometimes you want users to reinstall stuff
so that there's accurate dependency information available, rather
than because something has changed.
Maybe this could be solved by having two kinds of revisions: - One
would rebuild all as usually (for example, -r1...) - The other one
would only regenerate VDB and wouldn't change the installed files
(for example, -r1.1)
But I am not sure if it could be viable from a technical point
of view :(
eww, no. Using ${PVR} to detect how portage should update things
would be asking for trouble, imo. Besides, I don't think detection of
when to just update VDB is the issue. The main issue that I see is
- -how- VDB should be adjusted based on what changes are made to the
ebuilds. For instance, if minimum versions of deps are adjusted
in-place, should vdb be updated to match? what happens if the minimum
version of the currently-installed dep is below the new one? etc. etc.
Also, in theory an EAPI bump with nothing else changing should be
re-generatable in the VDB, but i have a gut feeling (no evidence, just
a feeling) that going from say, EAPI2 to EAPI5 without doing some of
the phase functions again (ie 'merge', maybe there are others that can
affect VDB?) will result in a different VDB from a regular rebuild.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlPObO0ACgkQ2ugaI38ACPCerQEAgTgQOvCDl0dbB5sOOZ4diBNs
cheQR18XFo7MsVBX3uUA/0zP1cAiWy1zAF+crrfCC42krtvGmSSiU4JG0dFo4452
=iNmo
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: don't rely on dynamic deps
On July 22, 2014 11:25:05 AM CEST, Pacho Ramos pa...@gentoo.org wrote: El mar, 22-07-2014 a las 10:32 +0200, Kristian Fiskerstrand escribió: [...] I find it somewhat curious that the difference between ~arch and stable hasn't been brought up in this discussion yet. IMHO a user on ~arch should expect a higher number of rebuilds, it _is_ after all testing, whereby at the point it reaches stable, the deps are hopefully more likely to be correct to begin with. Does anyone have any insight into where these changes most often occur? Well, I have seen multiple times of this kind of fixes being noticed by people running really old stable boxes. They notice them when they update to latest stable and, then, we need to fix depends raising the versions usually :/ Maybe this discussion should be focused on trying to think about how to standardize a way for distinguish between revision bumps needing full rebuild or only VDB updates :| As someone who regularly adds in dependencies without bumping (adding USE=selinux dependencies to the proper SELinux policy) because that would trigger lots of totally unnecessary rebuilds: +1 Wkr, Sven -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Tue, 22 Jul 2014 19:03:16 +0200 Sven Vermeulen sw...@gentoo.org wrote: As someone who regularly adds in dependencies without bumping (adding USE=selinux dependencies to the proper SELinux policy) because that would trigger lots of totally unnecessary rebuilds: Er... You do realise that doing that with dynamic dependencies leads to packages depending upon selinux that don't actually use selinux, right? Thus triggering lots of totally unnecessary rebuilds on an ABI change. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
On 22/07/14 20:11, Ciaran McCreesh wrote: On Tue, 22 Jul 2014 19:03:16 +0200 Sven Vermeulen sw...@gentoo.org wrote: As someone who regularly adds in dependencies without bumping (adding USE=selinux dependencies to the proper SELinux policy) because that would trigger lots of totally unnecessary rebuilds: Er... You do realise that doing that with dynamic dependencies leads to packages depending upon selinux that don't actually use selinux, right? Thus triggering lots of totally unnecessary rebuilds on an ABI change. Err, I believe he meant adding RDEPEND -only USE=selinux to pull in eg. sec-policy/selinux-dante from net-proxy/dante So, how does that exactly make packages depending upon selinux that don't actually use selinux Doesn't make any sense - Samuli
Re: [gentoo-dev] don't rely on dynamic deps
On 22 July 2014 19:25, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 7/21/14, 11:52 PM, Alexander Berntsen wrote: Michał has documented the shortcomings of dynamic deps in our wiki[0]. (Thank you!) This documentation also includes two of our possible solutions. [0] https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies Thank you, this is very useful. I didn't understand the issue much before reading that page. One question: why for Removal of a USE flag along with the relevant dependencies dynamic deps say revbump + unnecessary rebuild? What would happen without the revbump? 1. Improve dynamic-deps. This is, as Michał pointed out earlier in this thread a pipe dream. Agreed. 2. Remove dynamic-deps. This is what I think currently makes sense. +1 I also think it's the best option. Paweł Ok, we can side step this discussion partially: Lets pretend for a moment dynamic deps get banned. People will still unconsciously make that mistake and things will still break when they do. So we'll probably need a repoman check that is smart enough to know X is modified and compare the DEPEND fields with the previous incarnation prior to commit, and then at very least, warn people doing `repoman full` that they've modified the dependencies, and that a -r1 bump is thus highly recommended. And that check can be added *now* prior to banning/disabling dynamic deps. And people who want to pay attention to that warning can start doing it before policy dictates they must. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
[gentoo-dev] Re: don't rely on dynamic deps
Ian Stakenvicius a...@gentoo.org wrote: The main issue that I see is - -how- VDB should be adjusted based on what changes are made to the ebuilds. For instance, if minimum versions of deps are adjusted in-place, should vdb be updated to match? what happens if the minimum version of the currently-installed dep is below the new one? etc. etc. All these problems disappear with minor revisions: You have to install the minor revisions just like any major revision, just that some phases will be shortcut. In particular, if the new dependencies are not satisfied, you get conflicts as usual if you would want to upgrade to a new version with dependencies not being satisfied. Also, in theory an EAPI bump with nothing else changing should be re-generatable in the VDB, but i have a gut feeling (no evidence, just a feeling) that going from say, EAPI2 to EAPI5 without doing some of the phase functions again (ie 'merge', maybe there are others that can affect VDB?) will result in a different VDB from a regular rebuild. As far as I can see, the phase functions which can be skipped are those from EbuildExecuter. If a package is special and needs to execute these functions, then this package must not use minor revisions and needs to be recompiled. Howeer, these packages should be rather rare; I cannot even imagine a reason why this should be necessary. For merge only the regeneration of CONTENTS in /var/db/pkg should be skipped. Concerning the confusion with minor revisions, I think that just the version comparison function in portage needs to be tuned to ignore minor revisions unless an extra parameter minor is passed: This extra parameter is essentially only needed in the best function and in the check whether phases need to be run. The version comparison function should just return -2, 2, 0 (if minor is not passed or False) -2, 2, -1, 1, 0 (if minor True; the values +-1 mean that *only* the minor revision differs). For some parts (some eapi support, parts of EbuildExecuter and version comparison), I have already some patches ready for portage. However, I have almost no free time, and I am not familiar enough with python and portage to do the rest in a reasonable time (e.g. I cannot put some writable attribute to EbuildExecuter since apparently some python hack is used in portage which I do not understand). If there is interest, I can post my patches so far. Where? What is not included in these patches, and I will probably not find the time to include it: 1. The actual skipping of phases (since all my attempts to set some flag led to the python error that all attributes of EbuildExecuter are readonly :( ) 2. The modification of the merge phase to not regenerate CONTENTS 3. Reporting an error if minor versions are used with non-matching EAPI. Surprisingly, this needs a bigger rewrite, since the code generating the regular expression for the version handling is currently not appropriate to such an extension. 4. Updating of .tbz2 files - this is certainly a bigger work. 5. In particular, the patches could not be tested yet... I would suggest to postpone 3. and 4. until the decision is made...
Re: [gentoo-dev] Re: don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/07/14 20:40, Martin Vaeth wrote: If there is interest, I can post my patches so far. Where? If you think these patches are useful for Portage, please send them to dev-port...@gentoo.org. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPOslgACgkQRtClrXBQc7X58QD7BCSHxg3yiSynXe4EKpYk8R/n pZKQPCoJqQXFtkFyU/0A/2BTRMm8T60AzHFNlaeKudRPQ4EC8ACbkP8+v4C6XVoW =0GbF -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/07/14 20:44, Kent Fredric wrote: So we'll probably need a repoman check that is smart enough to know X is modified and compare the DEPEND fields with the previous incarnation prior to commit, and then at very least, warn people doing `repoman full` that they've modified the dependencies, and that a -r1 bump is thus highly recommended. And that check can be added *now* prior to banning/disabling dynamic deps. And people who want to pay attention to that warning can start doing it before policy dictates they must. This would be a good thing to do. Would you like to try implementing it? - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPOso8ACgkQRtClrXBQc7V7BgEAgElHG5RcxpJWS2eTQ7YVFdDX NZ55itqGeMngocAoitUA+QF4N0w07NrQSpPecPaF5AeuLOspGI7xjfaU/2BNFLGO =1H0R -END PGP SIGNATURE-
[gentoo-dev] Re: don't rely on dynamic deps
On Tue, 22 Jul 2014, Martin Vaeth wrote:
Ian Stakenvicius a...@gentoo.org wrote:
The main issue that I see is
- -how- VDB should be adjusted based on what changes are made to the
ebuilds. For instance, if minimum versions of deps are adjusted
in-place, should vdb be updated to match? what happens if the minimum
version of the currently-installed dep is below the new one? etc. etc.
All these problems disappear with minor revisions:
You have to install the minor revisions just like any major revision,
just that some phases will be shortcut.
In particular, if the new dependencies are not satisfied, you get
conflicts as usual if you would want to upgrade to a new version
with dependencies not being satisfied.
Other problems appear, though. Documentation is installed in a ${PF}
subdir, so install locations actually do change when updating the
minor revision. Also some method for updating binary packages would be
needed.
All in all, I'm not convinced if the cure wouldn't be worse than the
disease here. It would introduce another level of complexity, in order
to avoid a few rebuilds.
Ulrich
pgpzXNKhpbaKV.pgp
Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
Ulrich Mueller u...@gentoo.org wrote:
Other problems appear, though. Documentation is installed in a ${PF}
subdir, so install locations actually do change when updating the
minor revision.
Yes, the minor revisions should not be exported into the variables
of ebuild.sh. I had forgotten this.
Also some method for updating binary packages would be needed.
I already mentioned that. But even if this is not implemented,
this is only a minor issue.
All in all, I'm not convinced if the cure wouldn't be worse than the
disease here.
The disease is making the distribution almost useless
or having broken dependencies.
It would introduce another level of complexity, in order
to avoid a few rebuilds.
It seems you never counted the number of silent modifications
to the tree: Just compare the number of changed packages in
metadata/ with the number of packages shown by eix-sync...
I would guess it means roughly that you have to recompile your
whole installation once a week, 95% of the rebuilds being due to
not fixing the package manager to work properly with dynamic deps.
Actually, I still think that implementing dynamic deps correctly
would be better, but minor revisions do not exclude this
and are probably simpler to implement.
Re: [gentoo-dev] don't rely on dynamic deps
On 22/07/14 10:25, Paweł Hajdan, Jr. wrote: On 7/21/14, 11:52 PM, Alexander Berntsen wrote: 2. Remove dynamic-deps. This is what I think currently makes sense. +1 I also think it's the best option. Not before someone has implemented an alternative way to avoid useless rebuilding. The quality of the distribution doesn't improve by killing one of the most important features the package manager has. The quality of the distribution improves by providing an alternative with less problems. Sounds like to me, that the people who want to remove the feature so badly, are the ones volunteering for the job as well. - Samuli
Re: [gentoo-dev] don't rely on dynamic deps
Dnia 2014-07-22, o godz. 09:25:45 Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a): On 7/21/14, 11:52 PM, Alexander Berntsen wrote: Michał has documented the shortcomings of dynamic deps in our wiki[0]. (Thank you!) This documentation also includes two of our possible solutions. [0] https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies Thank you, this is very useful. I didn't understand the issue much before reading that page. One question: why for Removal of a USE flag along with the relevant dependencies dynamic deps say revbump + unnecessary rebuild? What would happen without the revbump? Well, for completeness I'll start by listing what would happen with static deps. Though nothing will actually happen. Already-built packages may have the flag enabled along with deps. When people rebuild -- through --newuse, --changed-use or otherwise -- they will get the functionality and dependencies removed along with the flag. How dynamic-deps would handle that are pretty much a matter of implementation choice. I can think of two major possibilities: 1. dynamic-deps are applied nevertheless. Since the relevant dependencies are removed along with the flag, dynamic-deps causes portage to no longer pull in needed libraries even though package was built with the flag enabled and still links to them. Long story short, linkage is broken. 2. PM notices IUSE no longer matches and doesn't apply dynamic-deps. While this prevents the breakage from happening, it's one additional point to the list of cases when dynamic-deps are disabled. Which means that no further dependency changes to the ebuild have dynamic effect and -- with current portage implementation -- the dependencies are 'reverted' to the state when the package was installed, even though just before the change portage used ebuild dependencies. Of course, you could try to invent some smart logic that would handle this specific case better. But it makes the dependency resolution even more complex and hard to understand, plus someone needs to actually do it. And then, you're going to hit even more corner cases and implement additional workarounds for each one. And then each of those workarounds will create new corner cases... -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: don't rely on dynamic deps
On Tue, 22 Jul 2014, Martin Vaeth wrote:
Ulrich Mueller u...@gentoo.org wrote:
Other problems appear, though. Documentation is installed in a
${PF} subdir, so install locations actually do change when updating
the minor revision.
Yes, the minor revisions should not be exported into the variables
of ebuild.sh. I had forgotten this.
That doesn't help. Imagine there is cat/foo-1 and the minor revision
is bumped. The new ebuild is cat/foo-1-r0.1 then, and PF changes even
if the minor revision is ignored (namely, from foo-1 to foo-1-r0).
Actually, I still think that implementing dynamic deps correctly
would be better, but minor revisions do not exclude this
and are probably simpler to implement.
The PM could just update the VDB whenever it detects that the metadata
of the ebuild has changed (relative to the VDB). You can get that
without introducing the additional complication of minor revisions.
Ulrich
pgpPZg59E8x2o.pgp
Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, Jul 22, 2014 at 11:42:30AM +0200, Alexander Berntsen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/07/14 02:36, hasufell wrote: William Hubbs: My concern about doing a revbump just because the deps change is that the new revision has to be committed in ~arch, so we then have to hit the arch teams, which we know are overworked anyway, with stable requests just because we changed the dependencies. Isn't that causing a lot of possibly unnecessary work for our arch teams? Procedure over logic? Just commit it straight to arch if repoman doesn't complain. William, this is, as Julian pointed out, a problem you can solve by changing your policies. This is not a problem related to the Portage software, in which dynamic-deps are broken. s/your/our/ Repoman refuses to commit if you try to go directly to stable without using --force. I'm just being cautious; I'm not sure whether this qualifies as the type of emergency situation where commiting directly to stable is a good thing or not. William signature.asc Description: Digital signature
[gentoo-dev] Re: don't rely on dynamic deps
Ulrich Mueller u...@gentoo.org wrote: The new ebuild is cat/foo-1-r0.1 then, and PF changes even if the minor revision is ignored (namely, from foo-1 to foo-1-r0). PF has to be filled correctly, of course: The versions foo-1 and foo-1-r0 are identical according to PMS and should thus lead to the same $PF. If this is currently not happening in portage, this is a bug which should be fixed, independently of whether minor revisions are introduced or not. Note that PR=0 in both cases. BTW: Even if PF would have the wrong value, this would not do any harm for minor revisions: If the minor revision has just changed, nothing is merged to the filesystem and /var/db/*/*/CONTENTS is unchanged, either. So nothing breaks in this case. If the user re-emerges the minor revision (and if PF would have the wrong value), then the minor revision would be visible to the user in the sense that the name of the Doc-Directory is influenced (and after a further minor revision bump, this revision number would be outdated). An arguable cosmetical issue, but nothing breaks, either. Actually, I still think that implementing dynamic deps correctly would be better, but minor revisions do not exclude this and are probably simpler to implement. The PM could just update the VDB whenever it detects that the metadata of the ebuild has changed (relative to the VDB). You can get that without introducing the additional complication of minor revisions. ...but by introducing all the additional complications Ian has mentioned. More precisely: What happens if new dependencies are introduced which are not satisfied? One has to face it: Portage must not just silently update the database and thus silently produce a /var/db which does not satisfy its own dependencies...
Re: [gentoo-dev] Using LINGUAS
Hello, LINGUAS is a concept in gettext tooling. I do not understand why we overload it in package management in the first place. It is an environment variable that we set up in make.conf, because that's an easy way to get it into the build environment to have the standard way of limiting translations work. By overloading it for IUSE_EXPAND we effectively make it pretty much impossible to have the choice of ALL translation files, except when it means extra packages; without conditional LINGUAS setting, that is. The standard LINGUAS variable acts as follows: If unset: Build all translations If set to an UNORDERED listing of language codes: Include translations for listed languages (or dialects) If set to an empty string or similar: Don't include any translations We currently have wrong behaviour for when it's unset, as as far as IUSE_EXPAND is concerned - we don't have a default that includes all available linguas as far as I know. Though in the real world, I don't think it matters much, and it's convenient for those that just build a gentoo machine for use within the family, with known language capabilities within. As a side note: LINGUAS does not only control which .mo files happen to be installed (which you could get rid of later easily with localepurge) - it also is used to filter out unwanted translations in files which have all the translations in the same file; this includes, but is not limited to .desktop files. This used to be a intltool thing, but nowadays gettext has derived such support directly as well. Mart
[gentoo-dev] Re: don't rely on dynamic deps
On Tue, 22 Jul 2014, Martin Vaeth wrote: PF has to be filled correctly, of course: The versions foo-1 and foo-1-r0 are identical according to PMS and should thus lead to the same $PF. This is not so. These versions are equal in comparision, so they cannot be in the tree at the same time. However, PF will be different for them. Note that this also occurs elsewhere. For example, versions 1.0.2 and 1.000.2 cound as equal, but again PF will be different. If this is currently not happening in portage, this is a bug which should be fixed, independently of whether minor revisions are introduced or not. Portage behaves as PMS specifies. PF is derived from the ebuild's name, without any normalisation to a canonical version. Ulrich pgpZXC19wJc9M.pgp Description: PGP signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
Am Dienstag 22 Juli 2014, 22:40:03 schrieb Ulrich Mueller: On Tue, 22 Jul 2014, Martin Vaeth wrote: PF has to be filled correctly, of course: The versions foo-1 and foo-1-r0 are identical according to PMS and should thus lead to the same $PF. This is not so. These versions are equal in comparision, so they cannot be in the tree at the same time. However, PF will be different for them. Well we'd need a new EAPI for this anyway. So we might as well redefine -r0 there. -- Andreas K. Huettel Gentoo Linux developer kde, council
Re: [gentoo-dev] don't rely on dynamic deps
Dnia 2014-07-21, o godz. 22:42:23 Samuli Suominen ssuomi...@gentoo.org napisał(a): So, -1, useless rebuilds is one of the biggest problems lately, [citation needed]. In other words, please support such claims with evidence. Because honestly I didn't see very much people complaining about unnecessary rebuilds, except in this specific thread. But I guess they're indeed a larger issue than, for example, portage forcing wrong branches of || dependencies or other dependency calculation errors that result in people being unable to update their systems. But I don't really visit Forums often. it's an relatively new problem, people are revbumping packages for the simplest things like EAPI4-5 If you ever happen to change EAPI in a stable ebuild without revbump, please be kind enough to revoke your own commit rights. Thanks. -- Best regards, Michał Górny signature.asc Description: PGP signature
