Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 08:10:20 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 22/07/14 04:05, Rick Zero_Chaos Farina wrote: And just for fun, since no one has mentioned it yet, dynamic deps don't work at all on binpkgs since the Packages file contains the deps (like vardb) and it doesn't get updated (just like vardb). Known long standing pitfall. It's managable. It is one of the reasons I see binpkgs as breaking progress instead of being part of the progress; it is manageable, but it could be better. Revbump or make dynamic deps actually work (ha). If they are really as broken people claim, why is the feature enabled by default in the official package manager? Why are these discussions resounding more strongly with each occurrence? As in, why I'm not seeing a bug with title sys-apps/portage: disable dynamic deps by default https://bugs.gentoo.org/show_bug.cgi?id=516612 with a Comment #0 listing all the culprits why it should be disabled by default? They've been gathered throughout this thread; yes, they could use a summary, but that doesn't change that all the culprits exist out there. Or do people think it works well enough, so that it's pros overweight the cons? I do, and many others seem to think so as well. Depends on what the pros and cons are; it makes the difference between merely thoughts and an actual reality, to construct towards a decision. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 21:53:04 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: Actually the quizzes are pretty much clear on that. 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. As suggested, later PMS features (eg. (+) / (-), ...) and PM features (eg. binpkgs, ...) can change that; so, a policy adaption or a clearly described workflow may at some point be necessary to stay actual. Now... whether dynamic deps are technically the right thing to do is another question. It merits discussion, but we need to be really sure about the consequences of any change. To deal with that one needs a clear workflow; given that it replaces an automatic feature or hack without much rebuilds, by something that needs you to decide whether or not to rev bump and cause more rebuilds. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 22:42:23 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Revision bumping for dependency change that doesn't cause the package's file content to change doesn't make sense; triggers useless rebuilds for users. A merged ebuild that misses a dependency needs an useless extra emerge. Think about the triggers instead of the extra rebuilds or extra emerges. Portage is the official package manager, and has dynamic deps enabled by default. Is it a feature or is it a hack? And it's already in ebuild-quiz.txt to ensure knowing when to, or not to, revbump: *** Ebuild technical/policy questions 1.You change a package's ebuild to install an init script. Previously, the package had no init script at all. Is a revision bump necessary? Why? What about when adding a patch? That's not about dynamic dependencies; but yes, too much rev bumps. So, -1, useless rebuilds is one of the biggest problems lately, it's an relatively new problem, people are revbumping packages for the simplest things like EAPI4-5 Useless triggers are the problem; why are the rev bumps needed, why are dependencies forgotten, ...? Sounds like a developer work flow issue... https://bugs.gentoo.org/show_bug.cgi?id=499852 -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 23:01:58 +0200 Jeroen Roovers j...@gentoo.org wrote: So you suggest we work around a bug in the PM which would be a single fix. Everywhere. Which bugs? Which fixes? Where? ... Did this thread spawn from nothing? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 17:52:51 -0500 William Hubbs willi...@gentoo.org wrote: 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? Rev bumps that only add dependencies shouldn't need separate STABLEREQs. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 22 Jul 2014 20:50:55 +0200 Alexander Berntsen berna...@gentoo.org wrote: 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? Just a side note, this would need VCS diff support in Repoman; there are some other feature requests on b.g.o that are also pending this VCS diff support, but it takes some understanding of the Repoman code. This becomes easier to implement after the refactor of Repoman completes; checks are organized and consolidated into several files due to the refactor, rather than mixed together in a giant single file. Having repoman help with the developer workflow sounds like a neat idea. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTzvOZAAoJEPWZc8roOL/QVcoH/0JhGPYQg5yPYDafriSIxpD+ ydS0jwCZudHiX7YZk/L5XiVLKTiwEPNLUzEmmYtkCnPXtJAZTFUYlTmn9sY9GUEh dV9Gr6gG5LpwjGDF2E9F5ivkSdUqGbx8ztqKibSAm4POy+uLm7EDEBtRJe095VVo k/kKukGSpa9hlnLB43hP9u1rs0vuwx0YB6FwK+dRVxGJAyPipgxg1jt6uRqOO9+a sBOzc910js8rpO1bkL4vGbrRViVUoFFOylWrXDxEuuyoaAWROZbItqe4xK2XagI3 wYJa/aLzGO9b3oTDQPVSEdIpgqfuJCI39BH4UrlAUZgT4GIuB8VroOx9MAOtHZc= =jVQd -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 23:11:37 +0200 Michał Górny mgo...@gentoo.org wrote: 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. Users are so used to broken dependency resolution that they don't complain about it very much, and even when they do, they're rarely able to identify the actual cause of the problem. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 22:05:54 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: 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. Those are apples with eggs; what you claim to be most important in itself also has problems as stated in this thread, it doesn't stop there as even beyond that it is a hack that deals with triggered problems. So, I don't think it is right to discuss replacing problems with problems. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] USE=gudev introspection removal from virtual/udev tomorrow'ish
gentoo-x86 has been converted to use virtual/libgudev. big thanks to _AxS_ who helped me to get it finally done. that means we will be removing compability USE flags gudev introspection from virtual/udev tomorrow'ish (only waiting for gnome-overlay folks) run this in your overlay: $ grep virtual.*udev.*gudev */*/*.ebuild and convert them to EAPI=5 syntax virtual/libgudev:= but don't do it without making sure you don't need virtual/libudev:= or virtual/udev (like for udevd, udev.pc for udevdir value) as well the Tracker is: http://bugs.gentoo.org/showdependencytree.cgi?id=506034hide_resolved=1
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 23:11:37 +0200 Michał Górny mgo...@gentoo.org wrote: [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. [citation needed]. Actually, please try to go a step further and reproduce it; surprise! If you ever happen to change EAPI in a stable ebuild without revbump, please be kind enough to revoke your own commit rights. Thanks. So much revocations. Thanks. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 21:34:10 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: On Mon, 2014-07-21 at 22:56 +0200, Michał Górny wrote: Yes, it does. I'm not sure if it leads anywhere, though. Dynamic deps are a pipe dream. You can't implement them properly, so we're using half-working implementation as an excuse to be lazy. Why not adapt the updates mechanism for modifying rdepends? Perhaps something like rdepends-add foo-bar/blah-3.14 wombat? ( =dev-libs/wombat-1.0 ) This would give the package manager all the benefits of static dep resolution while allowing us to dynamically make simple changes (like adding a missing dependency to an ebuild) without forcing users to rebuild the package. Thinking this through: 1) What about rdepends-change and rdepends-del? If you only support addition; you get the same problem as with things like pkgmove, changing and/or removing it could become somewhat problematic. 2) This needs two commits every time you want to do this; one commit for the updates/, another to keep the ebuild recent for (rev)bumps. 3) It'll be a lot of fun to attempt to support this in Repoman. 4) How do we clean up these entries? Doesn't this info grow fast? 5) The first paramater: Should that point to a single ebuild? Should that support ranges? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 19:37:17 + hasufell hasuf...@gentoo.org wrote: afaiu dynamic deps are broken and not defined in PMS It goes a step further than that! The PMS imposes certain limits on dependencies; it states that DEPEND must be present before executing src_* phases, that RDEPEND must be present before treating the results as usable and that PDEPEND must be done before finishing the batch of installs. http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-750008.1 If you attempt to fit in dynamic dependencies in that specification; the src_* phases could never run, the results can never be considered usable and the batch of installs can never finish. still... people seem to fix deps without revbumping, causing users who either don't use dynamic deps (it's optional for portage through --dynamic-deps=y, although it's on by default) or who use a different PM to not get the fix, at worst resulting in broken dependency calculation Why do we have a PMS if we don't take into account other PMs? Is Gentoo still a meta distribution? How does the Portage tree portage? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 21 Jul 2014 16:41:39 -0400 Ian Stakenvicius a...@gentoo.org wrote: I wonder if there may be some form of extension we could add to portage, such that it could do a VDB-only re-emerge somehow, when the in-tree ebuild doesn't match the in-VDB one. If that could be implemented properly (and i'm not sure that it could, tbh), maybe that would help reduce issues with dynamic deps, too... Hmm, dynamic dependencies ... dynamic rebuilds ... dynamic compilation; one day we will have hot code pushes where upstream changes immediately reflects itself upon one's system. Does such a gimmick succeed? Meteor! - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJTzuAsAAoJEPWZc8roOL/QNYsH/1uJrazScukDYnGj3lsPkl7P 5l7l7caugq5CwFfJ+VLZR5byV6MePBff+rJsO6Ch8v4yM+h+IFnOn7pLS27Oqm71 LRaGHeTH/pge3jq9mm53b7ABi2IjuNSKIr69/loYMJaNgHQLZCtR/wFVxKR3XFrA dhJN7WKhHAG0+1HRlNWCdYpHllG+cmayLARlwfWGbZii/OZWh0eAVEUV0pFdZwlP WaeOcnLebn+TFWPyKEkGKkmz7yI7fFMaoKBueEAZ9PwEUmhdSK5PEeY2U/OpLOA7 7wOYDe9J1k04q5DwLzZe9LvqjwjYtGIP4sL1/b+9TCw59+akKC+DmnDv67vuTHs= =wV/h -END PGP SIGNATURE-
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Tue, 22 Jul 2014 18:21:00 +1000 Michael Palimaka kensing...@gentoo.org wrote: What a great way to kill the distro. I can already heat my house with the number of unnecessary rebuilds Do you upgrade @world every hour and thus have it cause excessive heat? If I upgrade every X weeks they become much more cool and necessary... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 09:25:45 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: 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? Assuming dynamic dependencies don't exist, another package would still depend on the USE flag in the vdb; the only way to force that USE flag dependency to go away is with an unnecessarily rebuilding rev bump, as without it it would complain that the USE flag doesn't exist. (We're talking about RDEPEND=some/pkg[useflag] -- RDEPEND=some/pkg) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 22 Jul 2014 09:53:49 -0400
Ian Stakenvicius a...@gentoo.org wrote:
Using ${PVR} to detect how portage should update things
would be asking for trouble, imo.
This entire sub thread reads like a dynamic dependencies alternative in
disguise, the difference lies in an increase of the level of control
and in the place where this then gets reimplemented.
The increase of control comes from the maintainer being able to decide
whether the dependencies in the vdb are updated or not; however, this
gives rise to a mindset where you consider this level of control for
other variables as well (which syntax we'll [ab]use for that?) as well
as end up with more ebuilds for the sake of updating vdb dependencies.
Using an extension like -rX.Y seems odd; at the very least, I think an
incremental variable or something along that line in the ebuild would
work better. This allows for array usage like VERSION[dependencies]=1,
thus allowing other variables to be dynamic as well; you compare that
number against the one in the vdb, bingo...
Or is it just a figment?
Please think a design through and don't take a cheap shot with -rX.Y.
- --
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBAgAGBQJTzulZAAoJEPWZc8roOL/QzSMH/0wrGF+6joDtUlmUiNuTZBHB
Y0aYkr+Je7R4jj+NQxMY08j+odyImgnT+IrNrQcs7VEboXkrKS0s7ZEmQqCpNvmp
vVLvGUeAlzPgGz31aKIzMBhe5TuyCTwOvArU+DVcxDEktcbHP+sDBPTojQAr932e
qJtf6fdXDaUklu+MPlNofroREd2hjUrkS34ll6W5E+KizNMfRO7n4SAN38pkkE+C
4t3elp1I2Eei7HQT/cNUY78ab8Sgiy6N5CryN73zx6jyw9EwShLFV/8VN3M9SJ1B
jvBmD01EjsW6FLz6fvUPy2dz4GBKaC4YY0qhK5XocBwROUu2yCGV/w/es1JROB0=
=xuKt
-END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
Dnia 2014-07-21, o godz. 23:06:07 Pacho Ramos pa...@gentoo.org napisał(a): 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 :( I'm afraid it couldn't. The major problem is not knowing *when* to migrate metadata, portage usually gets that right. The problem is in getting the correct output which is often near to impossible. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 22:05:54 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: The quality of the distribution doesn't improve by killing one of the most important features the package manager has. Uh, that's a bit of an odd claim, given that dynamic deps often doesn't do what you're after anyway... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] gcc-4.8 may be needed in stable for www-client/chromium-38.x
Looks like www-client/chromium is going to start using c++11 seriously and require gcc-4.8+, see thread https://groups.google.com/a/chromium.org/d/msg/chromium-packagers/fvJvPG8fa7I/iWPEsUxhKikJ This is in the dev channel for now, but given the 6 weeks release cycle it'll go to stable in about 3 months, and every time it's a security update. I'm trying to get Gentoo prepared now, and so what are our chances to get gcc-4.8 to stable by that time? Possible alternative solutions: 1. Depend on clang, and force the build to use it. Possible problem with this is that since chromium uses very bleeding edge clang, this can put some strain on our system clang just as well. 2. Patch chromium to make it compile with gcc-4.7. This is almost always technically possible, but can be a maintainability burden, especially if upstream doesn't accept some parts of the patches. Also, there are known problem with chromium, c++11 and gcc-4.7 (https://groups.google.com/a/chromium.org/d/msg/chromium-dev/NrtrEnoMH6g/ERRiVAQcE18J , although Gentoo is not affected by this one because we have newer dbus). WDYT? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/07/14 04:51 PM, Andreas K. Huettel wrote: 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. I still don't follow why we need new EAPI for this, as presented. What we are talking about here is optional PM behaviour only, and a convention that developers will need to adopt. It doesn't much matter if a PM doesn't implement minor-revision-vdbonly-merging because that PM would just do a full re-emerge same as any other revbump. The only need for EAPI change that I can see is to allow non-integer revision values, but that wasn't on mva's list of changes from what I remember. Am I missing something else, here? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPPtWIACgkQ2ugaI38ACPCjBQD+K0aQW3lJqVUJTo1nO9nnFlsY NfrgaIuu6eescdN6FDkBALwizKGBI4I0iSmj2ywis/4OTNsvFBQm9sxywXq7HFz1 =3Ajb -END PGP SIGNATURE-
[gentoo-dev] Re: don't rely on dynamic deps
Kent Fredric posted on Wed, 23 Jul 2014 06:44:57 +1200 as excerpted: 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. Be aware that with eclasses generated deps taken into account, this /could/ trigger a LOT of arguably unnecessary revision bumps. Right now I'm trying emerge --dynamic-deps n --update --deep @world, and... Due to dynamic-deps and the (default) WANT_AUTOMAKE=LATEST (or whatever it is) stuff in the eclasses, I only have automake slots 1.11 and 1.14 installed here, but I still have well over 100 packages originally built with automake:1.13, that if I turn off dynamic-deps either need it pulled back in, or need to be rebuilt to pull in the automake:1.14 dep. I guess that's a variant of category 2 in the wiki list. It's a minor build-only dep change that doesn't need to be propagated immediately as the package is already installed, with dynamic-deps applying it immediately, but static-deps wouldn't apply it until a rebuild. As long as the older automake slot remains around to fill the dep, not a problem. Of course for users the fix is simple and what portage recommends, simply pull automake:1.13 back in (or don't let it be unmerged in the first place) and don't worry about it. I decided to go the rebuild route instead, here, and once I decided the number of rebuilds wasn't going to be easy to do with --tree giving me one at a time, I concocted a pipe involving bzgrep environment.bz2 to list them all so I could rebuild them in parallel, then did a wc -l on the output to get a count. But a repoman dynamic-deps checker might have flagged all those 125-ish package for revision-bump when automake:1.14 was introduced and thus became a dependency candidate. And I'm on ~arch, doing --deep --newuse @world updates routinely, with a not insignificant portion of my packages being live-ebuilds, so many of the package originally built with automake:1.13 have certainly been rebuilt by now, here. But I see a distinct possibility of an automake slot bump triggering thousands of rev-bumps, often to all available versions of a package at once, tree-wide. Meanwhile, one personal benefit to this discussion is that at least I understand now why merging a binpkg the other day pulled in some automake slot that depclean immediately wanted to remove. Binpkgs are static-deps and that one must have been built with that automake slot, but of course depclean was using dynamic-deps, so... Now I have a proper explanation for the behavior. =:^) -- 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] don't rely on dynamic deps
Samuli Suominen: 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. There seems to be a misunderstanding. The feature is already _optional_ and not even active in all circumstances (did you read the wiki entry?). If your ebuilds assume that random portage features are enabled, then that's pretty much undefined behavior. We can debate whether there are dependency changes not worth a revbump. We can debate how to reinstate dynamic deps support or how to update the VDB. But considering any of that as a blocker to fix a fundamental bug in dependency calculation, handling of VDB and PMS compatibility is close to being silly, I'm sorry.
Re: [gentoo-dev] Re: don't rely on dynamic deps
On 07/23/2014 09:36 AM, Tom Wijsman wrote: On Tue, 22 Jul 2014 18:21:00 +1000 Michael Palimaka kensing...@gentoo.org wrote: What a great way to kill the distro. I can already heat my house with the number of unnecessary rebuilds Do you upgrade @world every hour and thus have it cause excessive heat? If I upgrade every X weeks they become much more cool and necessary... Shouldn't we strive to avoid the unnecessary rebuilds in the first place? Doing updates on your schedule only avoids the symptom, not the problem.
Re: [gentoo-dev] don't rely on dynamic deps
On Wed, 2014-07-23 at 01:13 +0200, Tom Wijsman wrote: On Mon, 21 Jul 2014 21:34:10 -0400 Alexandre Rostovtsev tetrom...@gentoo.org wrote: Why not adapt the updates mechanism for modifying rdepends? Perhaps something like rdepends-add foo-bar/blah-3.14 wombat? ( =dev-libs/wombat-1.0 ) This would give the package manager all the benefits of static dep resolution while allowing us to dynamically make simple changes (like adding a missing dependency to an ebuild) without forcing users to rebuild the package. Thinking this through: 1) What about rdepends-change and rdepends-del? If you only support addition; you get the same problem as with things like pkgmove, changing and/or removing it could become somewhat problematic. rdepends-add is easy to implement: just append a string to RDEPENDS and reparse it. Deletion is trickier. It's clear what it means to delete an atom from a flat list of atoms. But specifying what it means to delete a part of a complex expression (conditionals, disjunctions) requires some careful thought. 2) This needs two commits every time you want to do this; one commit for the updates/, another to keep the ebuild recent for (rev)bumps. Yes, but that's just more incentive to migrate to git :) 3) It'll be a lot of fun to attempt to support this in Repoman. Ideally, repoman would suggest what you should add to updates/ when it detects that you are committing a change to an existing ebuild. 4) How do we clean up these entries? Doesn't this info grow fast? The point is to *not* clean up these entries for months/years. I want to address the situation where a users installs from an ebuild with wrong dependencies, the next day the ebuild gets its dependencies fixed in cvs, two weeks later the ebuild gets deleted from cvs, and only then the user resyncs. With our current dynamic depends, as well as with the proposed minor revisions mechanism, the user will still have a broken vdb. I want to make sure the user's vdb gets updated even when the ebuild in question is gone from portage. 5) The first paramater: Should that point to a single ebuild? Should that support ranges? Just like everything else in profiles/, so for now, that means a single dependency specification. If you want version ranges, they should be allowed in package.mask too :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] don't rely on dynamic deps
Sent from an iPhone, sorry for the HTML...
On Jul 22, 2014, at 6:44 PM, Tom Wijsman tom...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 22 Jul 2014 09:53:49 -0400
Ian Stakenvicius a...@gentoo.org wrote:
Using ${PVR} to detect how portage should update things
would be asking for trouble, imo.
This entire sub thread reads like a dynamic dependencies alternative in
disguise, the difference lies in an increase of the level of control
and in the place where this then gets reimplemented.
The increase of control comes from the maintainer being able to decide
whether the dependencies in the vdb are updated or not; however, this
gives rise to a mindset where you consider this level of control for
other variables as well (which syntax we'll [ab]use for that?) as well
as end up with more ebuilds for the sake of updating vdb dependencies.
Using an extension like -rX.Y seems odd; at the very least, I think an
incremental variable or something along that line in the ebuild would
work better. This allows for array usage like VERSION[dependencies]=1,
thus allowing other variables to be dynamic as well; you compare that
number against the one in the vdb, bingo...
Or is it just a figment?
Please think a design through and don't take a cheap shot with -rX.Y.
The thing about -rX.Y is that it allows this new-dynamic-deps thing to act like
a regular rev bump to any PM that doesn't bother to implement it (or dynamic
deps for that matter). Instant backwards-compatibility is a handy feature.
[gentoo-dev] Re: don't rely on dynamic deps
Alexander Berntsen berna...@gentoo.org wrote: If you think these patches are useful for Portage, please send them to dev-port...@gentoo.org. I submitted them to the gentoo.portage.devel mailing list as was recommended to me in a pm. I am sorry that due to lack of time and experience with python, I am currently unable to finish the work properly as it should be. However, I think it should become visible that the whole thing can be done rather unintrusive, even if I should have missed some places and one or two patches still are needed.
[gentoo-dev] Help needed with ebuilds for pear.horde.org
Hi All,
I am trying to create an ebuild for Egroupware 14.1. (released this month)
To find out the dependencies, I am going through the setup check and am stuck
with the following:
**
Checking PEAR pear.horde.org/Horde_Imap_Client (2.16.0) is installed: False
PEAR::Horde_Imap_Client is needed by: EMailAdmin. You can install it by
running: pear channel-discover pear.horde.org ; pear install
pear.horde.org/Horde_Imap_Client
**
If I run those commands, it works, however, I prefer to use ebuilds for the
dependencies.
I tried to create some based on existing ebuilds from the kolab overlay (they
also use the pear.horde.org channel), but even though the install seems to
work, it still isn't found.
I also tried to adjust an existing PEAR ebuild to:
**
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
inherit php-pear-r1
LICENSE=LGPL-3
SLOT=0
KEYWORDS=amd64
PHP_PEAR_CHANNEL=pear.horde.org
SRC_URI=http://pear.horde.org/get/${PEAR_PN}.tgz;
DEPEND=dev-php/PEAR-Horde_Channel
**
But I am unable to properly change the PEAR-channel.
I am certain I am missing something simple, but my google-fu is coming short.
If anyone is able to point me in the right direction, I would be very
grateful.
--
Joost Roeleveld
Re: [gentoo-dev] don't rely on dynamic deps
On Tue, 22 Jul 2014 20:01:55 -0400 Ian Stakenvicius a...@gentoo.org wrote: The thing about -rX.Y is that it allows this new-dynamic-deps thing to act like a regular rev bump to any PM that doesn't bother to implement it (or dynamic deps for that matter). Instant backwards-compatibility is a handy feature. ...but it doesn't actually solve the problem. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Mon, 21 Jul 2014 23:06:07 +0200 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) But I am not sure if it could be viable from a technical point of view :( This in no way solves the problem. Consider the following course of events: User installs foo-1.1-r1 Developer makes foo-1.1-r1.1 foo-1.1* is removed from the tree User syncs -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] don't rely on dynamic deps
On Wed, Jul 23, 2014 at 9:33 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 21 Jul 2014 23:06:07 +0200 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) But I am not sure if it could be viable from a technical point of view :( This in no way solves the problem. Consider the following course of events: User installs foo-1.1-r1 Developer makes foo-1.1-r1.1 foo-1.1* is removed from the tree User syncs An updates-like mechanism would help here, since the updates could persist longer. Also, the user is probably going to end up uninstalling foo anyway or updating it to a newer revision, which means that whatever was broken with -r1 will tend to become a bit of a moot issue. Portage doesn't really support hanging onto PVs that aren't in the tree all that well to begin with. Just a general comment not aimed at this particular part of the thread - a solution doesn't have to be perfect to be useful. If we come up with a good clean solution that avoids rebuilds in a half-dozen specific circumstances and we agree to only use it in those circumstances, there is no reason we can't use it, even if there is some other circumstance that will still require a revbump. I'm sensing in this thread that we're forcing ourselves to choose between a hack that can be applied 100% of the time but which can break randomly, or a hypothetical perfect solution that never breaks but which will probably never exist either. A solution that works 80% of the time and never breaks as long as it is properly applied is an acceptable compromise. Rich
Re: [gentoo-dev] Re: don't rely on dynamic deps
On Tue, Jul 22, 2014 at 4:06 PM, Martin Vaeth mar...@mvath.de wrote: ...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... While this is problematic, I think portage actually can handle this (but I haven't tested this recently). Portage already allows you to clean a package without its reverse deps leading to a system in exactly the state you describe. I believe portage will just try to bring the package back at the next emerge @world (or any other set containing the reverse dep). If there is a problem with the dependency version then the system is already broken anyway - portage just doesn't realize it. I think that allowing devs to instruct portage to update VDB with USE/dep/etc changes is potentially less problematic than having portage trying to guess what the right thing to do is. We could then either use that feature or revbump as appropriate under the specific circumstances. Ultimately I think the most important thing we need is for PMs to follow some kind of defined behavior. In our efforts to get portage to do the right thing we sometimes end up with a portage that does things that nobody really understands. Things like that tend to lead to convenience 95% of the time and head-banging the other 5%. I'm all for workarounds, but I'd advocate simple ones that lead to easily predicted behavior (and failure modes). I'd rather safely eliminate 70% of useless rebuilds than unsafely try to eliminate 90% of them. However, I do agree that we need to be sensitive to rebuilds. Rich
[gentoo-dev] Re: don't rely on dynamic deps
Tom Wijsman posted on Tue, 22 Jul 2014 23:47:48 +0200 as excerpted: On Mon, 21 Jul 2014 19:37:17 + hasufell hasuf...@gentoo.org wrote: afaiu dynamic deps are broken and not defined in PMS It goes a step further than that! The PMS imposes certain limits on dependencies; it states that DEPEND must be present before executing src_* phases, that RDEPEND must be present before treating the results as usable and that PDEPEND must be done before finishing the batch of installs. http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-750008.1 If you attempt to fit in dynamic dependencies in that specification; the src_* phases could never run, the results can never be considered usable and the batch of installs can never finish. How long have dynamic-deps been around? Since EAPI-0? Because if so, that interpretation must be incorrect, since EAPI-0 was defined as portage behavior at the time, and AFAIK, no EAPI since then has been approved without a working portage implementation. In the context of dynamic-deps I'd interpret the above to mean within a single portage session. What happens some sessions later when an ebuild's deps are dynamic-updated after a tree sync is an entirely new session, and unless I'm missing something, the above PMS requirements can be met within a single session with dynamic-deps. still... people seem to fix deps without revbumping, causing users who either don't use dynamic deps (it's optional for portage through --dynamic-deps=y, although it's on by default) or who use a different PM to not get the fix, at worst resulting in broken dependency calculation Why do we have a PMS if we don't take into account other PMs? Is Gentoo still a meta distribution? How does the Portage tree portage? This remains a valid question. (FWIW, after some cleanup I set dynamic-deps=n in defaultopts, and did my last update, about nine days after my last sync and update, without dynamic-deps. We'll see how it goes longer term. Tho I guess people like me who have been running --newuse --deep for ages are half-way-there already.) -- 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
[gentoo-portage-dev] [PATCH] repoman: warn when herd's email appears in maintaineremail section
Manuel Rüger noticed that most of haskell packages's 'metadata.xml'
contain duplicate information:
herdhaskell/herd
maintaineremailhask...@gentoo.org/email/maintainer
I've added a check against 'herds.xml's email aliases.
Now repoman warns about such redundancy:
metadata.warning 1
dev-haskell/text/metadata.xml: use herdhaskell/herd instead of
maintainer 'hask...@gentoo.org'
Quick scan [1] of tree revealed a lot of non-haskell packages
having redundancy: samba, xemacs, sci, gpe, etc, etc.
[1]: https://github.com/trofi/gentoo-qa/blob/master/check_herd.sh
Run in the root tree of gentoo-x86:
gentoo-x86 $ ~/portage/gentoo-qa/check_herd.sh | wc -l
571
# some examples:
gentoo-x86 $ ~/portage/gentoo-qa/check_herd.sh
./app-admin/haskell-updater/metadata.xml: emailhask...@gentoo.org/email
./app-editors/xemacs/metadata.xml:emailxem...@gentoo.org/email
./app-i18n/ibus-table-chinese/metadata.xml:
emailc...@gentoo.org/email
./app-portage/fquery/metadata.xml:
emailhask...@gentoo.org/email
./app-text/glosung/metadata.xml: emailtheol...@gentoo.org/email
... # a lot of haskell
./dev-lang/tcl/metadata.xml:emailtc...@gentoo.org/email
./dev-libs/Ice/metadata.xml:emailc...@gentoo.org/email
./dev-libs/cloog/metadata.xml: emailtoolch...@gentoo.org/email
./dev-libs/cvector/metadata.xml:emails...@gentoo.org/email
./dev-libs/iniparser/metadata.xml: emailsa...@gentoo.org/email
./dev-libs/isl/metadata.xml:emailtoolch...@gentoo.org/email
...
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
bin/repoman | 13 +
pym/repoman/herdbase.py | 21 +
pym/repoman/utilities.py | 19 +++
3 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/bin/repoman b/bin/repoman
index c36ace1..74a4d44 100755
--- a/bin/repoman
+++ b/bin/repoman
@@ -1762,6 +1762,19 @@ for x in effective_scanlist:
fails[metadata.bad].append(%s/metadata.xml:
%s % (x, e))
del e
+ # check if 'metadata.xml' contains redundant
+ #
'maintaineremailsome-h...@gentoo.org/email/maintainer'
+ # email address. Instead it should contain
+ # 'herdsome-herd/herd'
+ if herd_base is not None:
+ for m_email in
utilities.get_maintainer_emails_from_metadata(_metadata_xml):
+ herd_name =
herd_base.herd_by_herd_email(m_email)
+ if herd_name is not None:
+ stats[metadata.warning] += 1
+
fails[metadata.warning].append(%s/metadata.xml:
+use herd%s/herd
instead of maintainer '%s' % \
+ (x, herd_name, m_email))
+
# Only carry out if in package directory or check forced
if xmllint_capable and not metadata_bad:
# xmlint can produce garbage output even on success, so
only dump
diff --git a/pym/repoman/herdbase.py b/pym/repoman/herdbase.py
index c5b88ff..ae7c4e4 100644
--- a/pym/repoman/herdbase.py
+++ b/pym/repoman/herdbase.py
@@ -34,9 +34,10 @@ def _make_email(nick_name):
class HerdBase(object):
- def __init__(self, herd_to_emails, all_emails):
+ def __init__(self, herd_to_emails, all_emails, herd_email_to_herd):
self.herd_to_emails = herd_to_emails
self.all_emails = all_emails
+ self.herd_email_to_herd = herd_email_to_herd
def known_herd(self, herd_name):
return herd_name in self.herd_to_emails
@@ -47,6 +48,9 @@ class HerdBase(object):
def maintainer_in_herd(self, nick_name, herd_name):
return _make_email(nick_name) in self.herd_to_emails[herd_name]
+ def herd_by_herd_email(self, email):
+ return self.herd_email_to_herd.get(email)
+
class _HerdsTreeBuilder(xml.etree.ElementTree.TreeBuilder):
Implements doctype() as required to avoid deprecation warnings with
@@ -57,6 +61,7 @@ class _HerdsTreeBuilder(xml.etree.ElementTree.TreeBuilder):
def make_herd_base(filename):
herd_to_emails = dict()
+ herd_email_to_herd = dict()
all_emails = set()
try:
@@ -82,6 +87,11 @@ def make_herd_base(filename):
herd_name = _herd_name.text.strip()
del _herd_name
+ _herd_email = h.find('email')
+ herd_email = _herd_email.text.strip()
+ del _herd_email
+ herd_email_to_herd[herd_email] = herd_name
+
maintainers = h.findall('maintainer')
[gentoo-portage-dev] [PATCH] sets: introduce @changed-deps to update packages which need dep changes.
The @changed-deps set tries to compare RDEPEND and PDEPEND entries of
installed packages with ebuild counterparts, and pulls the ebuild
whenever the two are not in sync. This could be used, for example, to
clean up the system after disabling --dynamic-deps.
---
cnf/sets/portage.conf | 5 +
pym/portage/_sets/dbapi.py | 53 --
2 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/cnf/sets/portage.conf b/cnf/sets/portage.conf
index b73afb1..fd2c387 100644
--- a/cnf/sets/portage.conf
+++ b/cnf/sets/portage.conf
@@ -84,3 +84,8 @@ class = portage.sets.dbapi.UnavailableSet
# are not available.
[unavailable-binaries]
class = portage.sets.dbapi.UnavailableBinaries
+
+# Installed packages for which vdb *DEPEND entries are outdated compared
+# to the matching portdb entry.
+[changed-deps]
+class = portage.sets.dbapi.ChangedDepsSet
diff --git a/pym/portage/_sets/dbapi.py b/pym/portage/_sets/dbapi.py
index 384fb3a..9b2cb8b 100644
--- a/pym/portage/_sets/dbapi.py
+++ b/pym/portage/_sets/dbapi.py
@@ -1,17 +1,18 @@
# Copyright 2007-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
+import re
import time
from portage import os
from portage.versions import best, catsplit, vercmp
-from portage.dep import Atom
+from portage.dep import Atom, use_reduce
from portage.localization import _
from portage._sets.base import PackageSet
from portage._sets import SetConfigError, get_boolean
import portage
-__all__ = [CategorySet, DowngradeSet,
+__all__ = [CategorySet, ChangedDepsSet, DowngradeSet,
EverythingSet, OwnerSet, VariableSet]
class EverythingSet(PackageSet):
@@ -456,3 +457,51 @@ class RebuiltBinaries(EverythingSet):
bindb=trees[bintree].dbapi)
singleBuilder = classmethod(singleBuilder)
+
+class ChangedDepsSet(PackageSet):
+
+ _operations = [merge, unmerge]
+
+ description = Package set which contains all installed + \
+ packages for which the vdb *DEPEND entries are outdated + \
+ compared to corresponding portdb entries.
+
+ def __init__(self, portdb=None, vardb=None):
+ super(ChangedDepsSet, self).__init__()
+ self._portdb = portdb
+ self._vardb = vardb
+
+ def load(self):
+ depvars = ('RDEPEND', 'PDEPEND')
+
+ subslot_repl_re = re.compile(r':[^[]*=')
+
+ atoms = []
+ for cpv in self._vardb.cpv_all():
+ # no ebuild, no dynamic-deps to break it :)
+ if not self._portdb.cpv_exists(cpv):
+ continue
+
+ use, eapi = self._vardb.aux_get(cpv, ('USE', 'EAPI'))
+
+ def clean_subslots(depatom):
+ if isinstance(depatom, list):
+ return [clean_subslots(x) for x in
depatom]
+ else:
+ return subslot_repl_re.sub(':=',
depatom)
+
+ vdbvars = [clean_subslots(use_reduce(x, uselist=use,
eapi=eapi))
+ for x in self._vardb.aux_get(cpv,
depvars)]
+ pdbvars = [clean_subslots(use_reduce(x, uselist=use,
eapi=eapi))
+ for x in self._portdb.aux_get(cpv,
depvars)]
+
+ if vdbvars != pdbvars:
+ atoms.append('=%s' % cpv)
+
+ self._setAtoms(atoms)
+
+ def singleBuilder(cls, options, settings, trees):
+ return cls(portdb=trees[porttree].dbapi,
+ vardb=trees[vartree].dbapi)
+
+ singleBuilder = classmethod(singleBuilder)
--
2.0.2
[gentoo-portage-dev] [PATCH] QA-warn about systemd units using /etc/conf.d.
---
bin/misc-functions.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index 5ccf7c2..f24e78c 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -595,6 +595,21 @@ install_qa_check() {
done
fi
+ # Common mistakes in systemd service files.
+ if type -P pkg-config /dev/null pkg-config --exists systemd; then
+ systemddir=$(pkg-config --variable=systemdsystemunitdir systemd)
+ else
+ systemddir=/usr/lib/systemd/system
+ fi
+ if [[ -d ${ED%/}${systemddir} ]]; then
+ f=$(grep -sH '^EnvironmentFile.*=.*/etc/conf\.d'
${ED%/}${systemddir}/*.service)
+ if [[ -n ${f} ]] ; then
+ eqawarn QA Notice: systemd units using /etc/conf.d
detected:
+ eqawarn ${f//${D}}
+ eqawarn See:
https://wiki.gentoo.org/wiki/Project:Systemd/conf.d_files;
+ fi
+ fi
+
# Look for leaking LDFLAGS into pkg-config files
f=$(egrep -sH '^Libs.*-Wl,(-O[012]|--hash-style)'
${ED}/usr/*/pkgconfig/*.pc)
if [[ -n ${f} ]] ; then
--
2.0.2
Re: [gentoo-portage-dev] New meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The Portage team meeting will be Thursday 24th at 6pm. If you have some really good reason for it not be, let me know and I will at least consider rearranging 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/ iF4EAREIAAYFAlPP2OUACgkQRtClrXBQc7VNWgEAkDDPA68teIb5A9vq6y+/lb8e cXh6RkVRZ5AiO386nI8A/1zXT8RTyNoCGOIbv+q2cwwCt4B1cBo+hPD5AN+Fd614 =wLZQ -END PGP SIGNATURE-
[gentoo-portage-dev] [PATCH] repoman: warn when herd's email appears in maintaineremail section
Manuel Rüger noticed that most of haskell packages's 'metadata.xml'
contain duplicate information:
herdhaskell/herd
maintaineremailhask...@gentoo.org/email/maintainer
I've added a check against 'herds.xml's email aliases.
Now repoman warns about such redundancy:
metadata.warning 1
dev-haskell/text/metadata.xml: use herdhaskell/herd instead of
maintainer 'hask...@gentoo.org'
Quick scan [1] of tree revealed a lot of non-haskell packages
having redundancy: samba, xemacs, sci, gpe, etc, etc.
[1]: https://github.com/trofi/gentoo-qa/blob/master/check_herd.sh
Run in the root tree of gentoo-x86:
gentoo-x86 $ ~/portage/gentoo-qa/check_herd.sh | wc -l
571
# some examples:
gentoo-x86 $ ~/portage/gentoo-qa/check_herd.sh
./app-admin/haskell-updater/metadata.xml: emailhask...@gentoo.org/email
./app-editors/xemacs/metadata.xml:emailxem...@gentoo.org/email
./app-i18n/ibus-table-chinese/metadata.xml:
emailc...@gentoo.org/email
./app-portage/fquery/metadata.xml:
emailhask...@gentoo.org/email
./app-text/glosung/metadata.xml: emailtheol...@gentoo.org/email
... # a lot of haskell
./dev-lang/tcl/metadata.xml:emailtc...@gentoo.org/email
./dev-libs/Ice/metadata.xml:emailc...@gentoo.org/email
./dev-libs/cloog/metadata.xml: emailtoolch...@gentoo.org/email
./dev-libs/cvector/metadata.xml:emails...@gentoo.org/email
./dev-libs/iniparser/metadata.xml: emailsa...@gentoo.org/email
./dev-libs/isl/metadata.xml:emailtoolch...@gentoo.org/email
...
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
bin/repoman | 13 +
pym/repoman/herdbase.py | 21 +
pym/repoman/utilities.py | 19 +++
3 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/bin/repoman b/bin/repoman
index c36ace1..74a4d44 100755
--- a/bin/repoman
+++ b/bin/repoman
@@ -1762,6 +1762,19 @@ for x in effective_scanlist:
fails[metadata.bad].append(%s/metadata.xml:
%s % (x, e))
del e
+ # check if 'metadata.xml' contains redundant
+ #
'maintaineremailsome-h...@gentoo.org/email/maintainer'
+ # email address. Instead it should contain
+ # 'herdsome-herd/herd'
+ if herd_base is not None:
+ for m_email in
utilities.get_maintainer_emails_from_metadata(_metadata_xml):
+ herd_name =
herd_base.herd_by_herd_email(m_email)
+ if herd_name is not None:
+ stats[metadata.warning] += 1
+
fails[metadata.warning].append(%s/metadata.xml:
+use herd%s/herd
instead of maintainer '%s' % \
+ (x, herd_name, m_email))
+
# Only carry out if in package directory or check forced
if xmllint_capable and not metadata_bad:
# xmlint can produce garbage output even on success, so
only dump
diff --git a/pym/repoman/herdbase.py b/pym/repoman/herdbase.py
index c5b88ff..ae7c4e4 100644
--- a/pym/repoman/herdbase.py
+++ b/pym/repoman/herdbase.py
@@ -34,9 +34,10 @@ def _make_email(nick_name):
class HerdBase(object):
- def __init__(self, herd_to_emails, all_emails):
+ def __init__(self, herd_to_emails, all_emails, herd_email_to_herd):
self.herd_to_emails = herd_to_emails
self.all_emails = all_emails
+ self.herd_email_to_herd = herd_email_to_herd
def known_herd(self, herd_name):
return herd_name in self.herd_to_emails
@@ -47,6 +48,9 @@ class HerdBase(object):
def maintainer_in_herd(self, nick_name, herd_name):
return _make_email(nick_name) in self.herd_to_emails[herd_name]
+ def herd_by_herd_email(self, email):
+ return self.herd_email_to_herd.get(email)
+
class _HerdsTreeBuilder(xml.etree.ElementTree.TreeBuilder):
Implements doctype() as required to avoid deprecation warnings with
@@ -57,6 +61,7 @@ class _HerdsTreeBuilder(xml.etree.ElementTree.TreeBuilder):
def make_herd_base(filename):
herd_to_emails = dict()
+ herd_email_to_herd = dict()
all_emails = set()
try:
@@ -82,6 +87,11 @@ def make_herd_base(filename):
herd_name = _herd_name.text.strip()
del _herd_name
+ _herd_email = h.find('email')
+ herd_email = _herd_email.text.strip()
+ del _herd_email
+ herd_email_to_herd[herd_email] = herd_name
+
maintainers = h.findall('maintainer')
Re: [gentoo-portage-dev] New meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sorry, I got timezone confused! That's 7pm UTC 0. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPP2bsACgkQRtClrXBQc7Ve0gD/RAubU24M5RFRqcnJQCi5IkF8 zbPrZjqidLSB62//UP0BAIr0JZW7qX8OUcYtjADJal7mnpPe8UML/WtKCsmk7UKr =1FRm -END PGP SIGNATURE-
