Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On Thu, Jun 13, 2013 at 6:56 AM, Alexander V Vershilov wrote: > The main point that haskell ecosystem is very breaky and only latest > version is supported, so > the safest path is to be on a bleeding edge and patch inconsistent > applications. So if one > package gets updated then commonly we need to fix its reversed deps, > if it were in tree than > we would be involved into stabilization process and in the end will > delay updating deps, and > the difficulty of tracking all version variant will be much higher > than no, at the end the quality > of the packages in tree will fall. Really we can _guarantee_ that > everything work in overlay > but there is either no technical or bureaucracy reasons that prevent > from fixing as soon as > possible. Still seems like working in gentoo-x86 without doing stabilization would cover most of those bases. Working in the unstable main tree is still a lot better than keeping stuff out there in an overlay, IMO. Cheers, Dirkjan
Re: [gentoo-dev] rfc: [patch] bash-completion-r1.eclass: add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)
On 13/06/13 07:58, Michał Górny wrote: Dnia 2013-06-13, o godz. 01:22:11 Samuli Suominen napisał(a): what $subject says, "add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)" http://bugs.gentoo.org/472938 ie. the pkg-config file shipped *now* in portage is a hack from me to postpone this pretty tired so more eyes is cool ;) You mean http://thread.gmane.org/gmane.linux.gentoo.devel/85258 ? I think you've got to convince ulm in the first place. His concerns was actually already covered by the first post and the linked bug: This is required for smooth migration path from old to new directories. Back when the old thread happened, there was only one possible value for completions dir, now there is two. And nothing prevents upstream adding/changing the values in the .pc file yet again for next release, this should be dynamic -- just like $(get_udevdir), $(get_libdir) etc.
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dnia 2013-06-12, o godz. 13:23:04 Michael Orlitzky napisał(a): > We need worse support for overlays, i.e. no. Having to use >3 overlays > defeats the purpose of a QA'd tree. Everything in an (official) > overlay should be in package.mask instead. The main reason it isn't is > because nobody wants to use CVS. For good examples, see sunrise or > gentoo-haskell. Sunrise is not that good example. I liked to use it as an example but over time you start to see how degenerated it becomes. It seems that the bond between people is pretty poor there, and many of the packages lack proper maintenance. Some of them simply don't build at all and wait for a random Sunrise user to fix them. Then they lay unmaintained once again, and the story repeats. - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJRuVxUXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKY3gP/2EnN/dhh11Br7mMW2uyojIf 6/kmuS+r2FsarD844WazUCEgFlxFZFyg2KBER2FrF1Ke39yiMpxIYBEL1L6fw4oZ uZVw9Sxjdkm+uVTdTXoSPS1EJcLbjVcWCykEXfs9VkN88xLrarfr6QwWtPvnV8mT Pdtoa7NsvvR8Ch1a4iHY/6l5gJgEVptY/uFJeyJf9uV23fIKZ7xASNON0TwSYdZN AnsHFuC2CVx228Yh3XOjAHazO25QblwrOhHQdrgmh54mYAP2G6AkqsleKr/zSxT8 JwI7gYeinPIjsq9mn/wtCRq0ilFYX1RjK43YfeKoUGIY1yZz6RHyHKr+jvOyEHod BHMcjORQpIV6RNk4mrPPvlw85mgMMIy3lulXdlb48GIMCzdL7h62Ng0SdYXYVDIo 7d8zys/QdnVlqjfYHJPiGXvlHt2mm62Fi6Jvndp/3L2xfjEf9oIe/l4jK09J8vjr LjumvpOe+O09IZ+O4J+xOPidCmKzvye6L/Irg8T1wKLr5A4nSIDRny57z7iNZlym uKJHF7Nfg7lciIqEBBo8a3U2CmAhlC5b1kGJQ6hV7jKGKOVM7FwF//1UMFZVwpsc DNgBor/qvAnRbmZBm0Xxdo8rUeyp3N6xnxzlFVv2gKtStGkZPEaambzNB5Lne/u7 s4GWAvN4AtmdT9Iu67S5 =ZoAv -END PGP SIGNATURE-
Re: [gentoo-dev] Introduce global dmalloc USE flag?
Dnia 2013-06-13, o godz. 09:35:54 "Dennis Lan (dlan)" napisał(a): > also > 4) app-admin/conserver > 5) net-nds/ypbind > 6) net-fs/samba > 7) net-analyzer/scli > 8) net-analyzer/traceproto > 6) net-misc/siproxd > > use dmalloc but controlled under USE=debug Do those use USE=debug solely for dmalloc or does it imply other stuff? Therefore: will it be possible to use USE=dmalloc in those packages? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: [patch] bash-completion-r1.eclass: add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)
Dnia 2013-06-13, o godz. 01:22:11 Samuli Suominen napisał(a): > what $subject says, > > "add support for pkg-config for migration to the new upstream defined > bash-completion directories (prereq for bug 472938)" > > http://bugs.gentoo.org/472938 > > ie. the pkg-config file shipped *now* in portage is a hack from me to > postpone this > > pretty tired so more eyes is cool ;) You mean http://thread.gmane.org/gmane.linux.gentoo.devel/85258 ? I think you've got to convince ulm in the first place. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
> The main reason it isn't is because nobody wants to use CVS. For good > examples, see sunrise or > gentoo-haskell. As a part of gentoo-haskell team, I'd like to say that CVS issue is not strongest one, there are much more meaningful reasons for having much stuff in overlays at least for haskell. IMHO: The main point that haskell ecosystem is very breaky and only latest version is supported, so the safest path is to be on a bleeding edge and patch inconsistent applications. So if one package gets updated then commonly we need to fix its reversed deps, if it were in tree than we would be involved into stabilization process and in the end will delay updating deps, and the difficulty of tracking all version variant will be much higher than no, at the end the quality of the packages in tree will fall. Really we can _guarantee_ that everything work in overlay but there is either no technical or bureaucracy reasons that prevent from fixing as soon as possible. All above is applicable because in overlay we work on programmers libraries, with enduser applications (that are synchronized with portage tree) situation is slightly different. -- Alexander
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On Wed, Jun 12, 2013 at 4:10 PM, Andreas K. Huettel wrote: > > Ah btw how's that git migration coming along? > Even though we're drifting here an update is probably due. At this point I'd say we have pretty high confidence that we can accurately migrate the tree. The issues that remain shouldn't hold us back from just moving forward (they're issues with cvs keywords that are already issues in cvs). The bigger issues were all fixed (like mangling unicode). Infra changes aren't started, and those are probably rate-limiting at this point, especially since it is hard for anybody not in infra to contribute to this. We also need to write up docs, and once an actual workflow is announced I suspect we'll start getting objections. The likely conflict I see is between those who want all commits in the log to be signed (which means no rebasing), and those who don't want any merge commits in the log (which means always rebasing unless you are REALLY fast). Anybody who wants to chip in on this one feel free to do so - I would like to but haven't gotten around to it yet. Rich
Re: [gentoo-dev] Introduce global dmalloc USE flag?
On 13 June 2013 13:35, Dennis Lan (dlan) wrote: > HI ALL: >Is it ok to introduce USE=dmalloc global flag? description as following > "dmalloc - Enable debugging with the dmalloc library" > > current consumers: > 1) net-fs/autofs > 2) net-misc/directvnc > 3) sci-biology/yass > > also > 4) app-admin/conserver > 5) net-nds/ypbind > 6) net-fs/samba > 7) net-analyzer/scli > 8) net-analyzer/traceproto > 6) net-misc/siproxd > > use dmalloc but controlled under USE=debug > > Dennis Lan > > Questions for clarity: 1. I haven't used dmalloc before, what does this use flag do for me? 2. How does this use flag change the built binaries? does it: a) make no user visible changes, but adds code instrumentation paths which can only be seen/understood with a special visualiser b) add output to TTY for the built binary? etc. I'm not arguing against global USE for it, I'm just asking for a USE description that is more meaningful. ie, alternatives might be: "Add runtime debug output via the dmalloc library" or "Add runtime instrumentation for the dmalloc debugger", or something like that. Because if it were case a), then I might be inclined to turn it on arbitrarily ( depending on how much it impacts performance ), just in case I happen to need it one day. But if it were case b), I'd be inclined not to turn it on arbitrarily, because I can see that would be irritating =) -- Kent
[gentoo-dev] Introduce global dmalloc USE flag?
HI ALL: Is it ok to introduce USE=dmalloc global flag? description as following "dmalloc - Enable debugging with the dmalloc library" current consumers: 1) net-fs/autofs 2) net-misc/directvnc 3) sci-biology/yass also 4) app-admin/conserver 5) net-nds/ypbind 6) net-fs/samba 7) net-analyzer/scli 8) net-analyzer/traceproto 6) net-misc/siproxd use dmalloc but controlled under USE=debug Dennis Lan
Re: TLDR: rant in support of overlays (was: Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays)
On 06/12/2013 06:31 PM, Greg Turner wrote: > On Wed, Jun 12, 2013 at 10:23 AM, Michael Orlitzky > wrote: >> On 06/12/2013 01:13 PM, Ciaran McCreesh wrote: >>> On Wed, 12 Jun 2013 19:05:29 +0200 hasufell >>> wrote: > Isn't it more an indication that Gentoo needs better package > management support for overlays? >>> No. >>> >> >> We need worse support for overlays, i.e. no. Having to use >3 overlays >> defeats the purpose of a QA'd tree. > > Disclaimer: I'm not a Gentoo developer -- actually, fuck that noise, I > am a Gentoo developer. But you know what I mean. My knowledge of the > gentoo QA process is limited to what I've been able to glean as a > beneficiary of the work and a limited participant via the bugzilla > system. The precise mechanisms and policies that drive Gentoo QA are > actually fairly opaque to me. > > Anyhow... wrt overlays "defeating the purpose" of QA: overlays may or > may not prevent the QA process from pertaining to users of overlays, > depending on the nature of the overlays. But, in fact, far from > defeating the purpose and integrity of Gentoo QA, my belief is that by > providing a standard baseline that QA may rely upon, overlays serve to > enhance and protect Gentoo's quality. E.g. https://bugs.gentoo.org/show_bug.cgi?id=341807 Overlays aren't tested against one another. As you add more overlays, the probability of brokenness approaches unity. You're not allowed to commit broken shit to the tree, so adding your packages to gx86 implies that it works with the rest of the packages in gx86.
TLDR: rant in support of overlays (was: Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays)
On Wed, Jun 12, 2013 at 10:23 AM, Michael Orlitzky wrote: > On 06/12/2013 01:13 PM, Ciaran McCreesh wrote: >> On Wed, 12 Jun 2013 19:05:29 +0200 hasufell >> wrote: Isn't it more an indication that Gentoo needs better package management support for overlays? >> >>> No. >> > > We need worse support for overlays, i.e. no. Having to use >3 overlays > defeats the purpose of a QA'd tree. Disclaimer: I'm not a Gentoo developer -- actually, fuck that noise, I am a Gentoo developer. But you know what I mean. My knowledge of the gentoo QA process is limited to what I've been able to glean as a beneficiary of the work and a limited participant via the bugzilla system. The precise mechanisms and policies that drive Gentoo QA are actually fairly opaque to me. Anyhow... wrt overlays "defeating the purpose" of QA: overlays may or may not prevent the QA process from pertaining to users of overlays, depending on the nature of the overlays. But, in fact, far from defeating the purpose and integrity of Gentoo QA, my belief is that by providing a standard baseline that QA may rely upon, overlays serve to enhance and protect Gentoo's quality. consider: emerge --info provides the overlays in bug reports to gx86 package maintainers and, if there is doubt about the sanity of the overlays, maintainers are (I presume) free not to support nonstandard configurations. But if a bug-reporter has this problem, the overlay system actually protects them. If they feel they are left high-and-dry due to their nonstandard gentoo installation, and are sure that their bug is a legitimate gx86 bug, they are free to whip up a virtual machine or to temporarily drop their overlays and CFLAG rice and emerge --depclean && emerge -e system. Assuming they turn out to be right, bug reporters and package maintainers can be sure to be roughly on the same page wrt reproducibility. Indeed, no matter what kind of personality conflicts or other nontechnical issues may be at play, the reporter of a legitimate bug is pretty much guaranteed to get some kind of resolution to his issue, or at least that has been my experience. If bug reporters don't like those results and want to implement a different solution than the one they got, overlays enable them to do that as well. In short, overlays permit Gentoo to maintain reasonable quality standards while encouraging innovation and casual experimentation. Larry the Cow approves of them. > Everything in an (official) > overlay should be in package.mask instead. The main reason it isn't is > because nobody wants to use CVS. For good examples, see sunrise or > gentoo-haskell. Such a policy might be OK for developers who are able to just hop on and make changes to gx86 without going though the whole bugzilla process, hence "official". However, it seems like you're thinking of overlays as piles of package ebuilds which haven't yet made it into stable. They may be that, or they may not -- overlays can add profiles, modify core eclasses, or even replace portage itself with a customized variant, and who knows what else. As another poster pointed out sarcastically, the GSOC types of projects clearly don't comport well with this, even if certain things like, i.e., sunrise, arguably might. Anyhow, isn't the gentoo-x86 tree already plenty big enough, without every single overlay's ebuilds and eclasses in there too? Personally, I'm inclined to wish it was smaller, even if that meant more stuff was pushed into overlays, although I suppose that might have a negative impact on QA coverage without some corresponding changes on the QA end of things... I guess I don't know enough about it to speak confidently. As a huge consumer of the overlay and layman mechanisms, both as a user and a developer, there is absolutely no doubt in my mind that by far the gravest problem with the overlay architecture is its inability to create direct VCS connectivity between an overlay and its upstream PORTDIR (coupled with it's requirement to clone entire package directories instead of overriding them on a per-file basis). FWIW, I have nascent ideas about how to fix that, but they are quite radical, probably half-baked (even just as vaporware ideas), and arguably off-topic, so I won't elaborate. -gmt
[gentoo-dev] rfc: [patch] bash-completion-r1.eclass: add support for pkg-config for migration to the new upstream defined bash-completion directories (prereq for bug 472938)
what $subject says,
"add support for pkg-config for migration to the new upstream defined
bash-completion directories (prereq for bug 472938)"
http://bugs.gentoo.org/472938
ie. the pkg-config file shipped *now* in portage is a hack from me to
postpone this
pretty tired so more eyes is cool ;)
--- bash-completion-r1.eclass 2013-06-13 01:09:24.933961265 +0300
+++ /tmp/bash-completion-r1.eclass 2013-06-13 01:08:51.846963274 +0300
@@ -9,7 +9,7 @@
# @EXAMPLE:
#
# @CODE
-# EAPI=4
+# EAPI=5
#
# src_install() {
# default
@@ -17,12 +17,55 @@
# newbashcomp contrib/${PN}.bash-completion ${PN}
# }
# @CODE
+#
+# @CODE
+# EAPI=5
+#
+# src_configure() {
+# econf \
+# --with-udevdir="$(get_bashcompdir)"
+# }
+# @CODE
+
+inherit toolchain-funcs
case ${EAPI:-0} in
0|1|2|3|4|5) ;;
*) die "EAPI ${EAPI} unsupported (yet)."
esac
+_get_bashdir() {
+ if $($(tc-getPKG_CONFIG) --exists bash-completion); then
+ echo "$($(tc-getPKG_CONFIG) --variable=$1 bash-completion)"
+ else
+ echo $2
+ fi
+}
+
+# @FUNCTION: get_bashcompdir
+# @RETURN: completionsdir value from bash-completion.pc if it's available
+# @DESCRIPTION:
+# If bash-completion.pc pkg-config file is available, query the correct
+# "completionsdir=" value and return it
+# Otherwise fallback to /usr/share/bash-completion/completions
+get_bashcompdir() {
+ if has_version '
RE: [gentoo-dev] Over-reliance of Gentoo projects on overlays
> -Original Message- > From: Michał Górny [mailto:mgo...@gentoo.org] > Sent: Wednesday, June 12, 2013 9:51 AM > To: Gentoo Developer Mailing List > Subject: [gentoo-dev] Over-reliance of Gentoo projects on overlays > Hello, > > I'd like to raise another issue I've met again recently. Shortly put, > some of our projects are relying too much on their overlays. The net > result is that some of their packages in the tree are not well-tested, > semi-broken and users end up being hurt by that. On the other hand, if those overlays' code, due to lack of sufficient manpower, interest, code quality, or whatever, is not able to bubble up through whatever chain of upstreams, perhaps the broken ebuilds or eclasses should be removed from gx86 or have non-gx86-compatible features masked or removed, so that overlay-specific code or features are maintained downstream, in the overlays that service them. In short, is it not the idea that non-masked gx86 stable, (and, to a lesser extent, non-masked gx86 ~arch) should contain easy-to-use, working ebuilds for the vast majority of users and standard use-cases, whereas overlays, even official overlays, are free to implement whatever quality standards suit the needs of the projects that administer them? Although there are clearly some Bad Things about overlays as a means of communicating features to end-users and organizing development, I'm not sure this implies there's anything wrong with the overlay mechanism per-se. These Bad Things may, instead, arise from deficiencies in the modularity of ebuilds or portage itself. Perhaps you should mention the specific bathwater you'd like to see thrown out, and, from there, folks can help determine where, if anywhere, is the baby? -gmt
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
Am Mittwoch, 12. Juni 2013, 18:59:48 schrieb hasufell: > On 06/12/2013 06:51 PM, Michał Górny wrote: > > Teams, what are the main reasons for keeping that much stuff in > > overlays? > > It's a mix of easier workflow especially for contributors and less > responsibility/noise in case of bugs. > > If there is a bug in an overlay, you rather expect people to come up > with a pull request. > Ah btw how's that git migration coming along? [/me runs and hides] -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/12/2013 01:13 PM, Ciaran McCreesh wrote: > On Wed, 12 Jun 2013 19:05:29 +0200 hasufell > wrote: >>> Isn't it more an indication that Gentoo needs better package >>> management support for overlays? > >> No. > > You make a persuasive argument. I realise now that the Summer of > Code projects for this were a mistake. > > We need worse support for overlays, i.e. no. Having to use >3 overlays defeats the purpose of a QA'd tree. Everything in an (official) overlay should be in package.mask instead. The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or gentoo-haskell. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRuK54AAoJEBxJck0inpOiHCsP/ivXsWF4GMYNkzNTCYLUmTZI hXXuF2ZEx6c1nlml/BXNtmABFcE6IO6GthLqLW7P6lmVyxy9E5jtDXD6Hht2H05K JLP57LO9dUjHZDeZeElkQDhZ1BHWFhTA0wAvzZqodGtjUiuxDFvp58E8iVvnnqw+ b852Y5bSh1hNPeb6c/P/tcRekOrz8k98LBlJny+rmw6AlRZLcieeKcTe5XPhRD6s QE79saIDThrqRn2fvkgdSMYJ0XR3FfkFWDeRopcilIJwm6+gjmkzGmXjBFkjG0g5 ImpeCtjL/0m/2gjUhKcJIYCNYxM/TD8K0MFRUpXLPX6jd76U1IL77UmTWMNz2r7m 2Rlr8gkvn9Iutlw1mhcLjYe6gaypfnDDv7rPZiJlLbSMY9XLwB3tLwatUzbEveBw Bn0AliHppphdA7cs50C7DlAw6cLTZKsdGlqTQJWaMxNHyXftYRQb65zD1AhfMawr /1XQ97cUHtozySdPMHaQVwrm0I7FxUtuV1z3x484gEgvn184u3XLnJIxRB8+ykhP vM/Az7GmGqNzDUeOFBKi1GHjQRlniMZPCOv43/QaKrN6t1Sjnrl68zuYEW5ujf/g tPUnLnVWl8vRQ6PZYE4OfipT9ovaTJFivRpXHWER6FTIIeBoypWfIYCnV5hNCOUL t6uIkp0UbYWl2RAL+ZIM =tHMl -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/12/2013 07:13 PM, Ciaran McCreesh wrote: > On Wed, 12 Jun 2013 19:05:29 +0200 hasufell > wrote: >>> Isn't it more an indication that Gentoo needs better package >>> management support for overlays? > >> No. > > You make a persuasive argument. I realise now that the Summer of > Code projects for this were a mistake. > > Your conclusion is not related to my answer. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRuK27AAoJEFpvPKfnPDWzTEoH/RRYSfZqrwE0YdbvoFi8Df/x yN+XUn95Dt9k08XGa6uhSdKc0U+hxjuP7JRE6C1lfV3M+sgegA5l+mEZSo0WeZmO xjMGykbLEIxAmUGmRTu1Hroy7R9RoRQKKF9aQ6VlwjmcbsxhVYpNJis/UY4sHrxe 7yygdcgpzMkT3rCZDdLyxUS5RCfOevVftImkmD/RlXayjHvqJDx8yisCxd4Ws2ll VR+xaTOe5UlTAxKj1t0qtIhd332tFsVY2+5XUtTkv3Ay0E6fd7t9GNvh+lUvoZfJ 0KT7Zz3dsuduerIoWBBy60c3G4A4mITlFwiOou4oEgE44L0Z/LBZheJGL6SFes4= =ASxW -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 12 Jun 2013 19:05:29 +0200 hasufell wrote: > > Isn't it more an indication that Gentoo needs better package > > management support for overlays? > > No. You make a persuasive argument. I realise now that the Summer of Code projects for this were a mistake. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlG4rCsACgkQ96zL6DUtXhGtggCfXAKVZ6hTDOuoJyFkXSfD0hRX qo0An0wvJBcu7LNaPT7ybIbeFaVECScz =wzUv -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/12/2013 07:02 PM, Ciaran McCreesh wrote: > On Wed, 12 Jun 2013 18:59:48 +0200 hasufell > wrote: >> On 06/12/2013 06:51 PM, Michał Górny wrote: >>> >>> Teams, what are the main reasons for keeping that much stuff >>> in overlays? >>> > >> It's a mix of easier workflow especially for contributors and >> less responsibility/noise in case of bugs. > >> If there is a bug in an overlay, you rather expect people to come >> up with a pull request. > >> Herds relying heavily on overlays and their portage packages >> being far behind their overlay is just a prove that the herd is >> dying and needs assistance. That goes especially for science. > > Isn't it more an indication that Gentoo needs better package > management support for overlays? > > No. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRuKpZAAoJEFpvPKfnPDWza5EH/3Oc6ytKY9jH88DSWKO+WIeW eXv49f0SL2+VOGdpZ7as4rZSTNBktCsLAuug05F+iQyCOhXBQkYYetLJPEt6W7Fa LSMFFov2/jdGLIN1WhNzCHpjpvKs2vx5A28jcm/Iz6liYkSYw4jbd1MP0gb0pKBT 8oaUNL3KVQGhPJekEF+9+W/akeXoy5cCGUbngWghZtAhAN3k/H+QRsmToaq1/yK8 BnrHv9UXnh88k3KbAhrvfNjce8Oom6/Gf3XS7MjBxnQM323CbrZzoj0fJL6czvLa safA3gaVSTkK+FGmaz9oZv+hqmNUG1wWa020jt/UP88zVuQZoRr3y6yS9fDVKUo= =en4R -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 12 Jun 2013 18:59:48 +0200 hasufell wrote: > On 06/12/2013 06:51 PM, Michał Górny wrote: > > > > Teams, what are the main reasons for keeping that much stuff in > > overlays? > > > > It's a mix of easier workflow especially for contributors and less > responsibility/noise in case of bugs. > > If there is a bug in an overlay, you rather expect people to come up > with a pull request. > > Herds relying heavily on overlays and their portage packages being far > behind their overlay is just a prove that the herd is dying and needs > assistance. That goes especially for science. Isn't it more an indication that Gentoo needs better package management support for overlays? - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlG4qcIACgkQ96zL6DUtXhGkvQCeOCoIQfdBLNifJxQpGmC0UOrO yZ8An0LmIV8S8AjIaSU5IVDeHa4RuysV =8keM -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/12/2013 06:51 PM, Michał Górny wrote: > > Teams, what are the main reasons for keeping that much stuff in > overlays? > It's a mix of easier workflow especially for contributors and less responsibility/noise in case of bugs. If there is a bug in an overlay, you rather expect people to come up with a pull request. Herds relying heavily on overlays and their portage packages being far behind their overlay is just a prove that the herd is dying and needs assistance. That goes especially for science. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRuKkEAAoJEFpvPKfnPDWzafoH/3YI+qPoOUuAUka7KjEtUMgP Y2duMnyIxlYFGQF9VYCT6ARNdg87qACbPKgYhI0ExxQrKZ7BC4m+IJCpiUdzUQW5 BiKnk80KMp1Tdl98b/5EmODwkmQeEmGTlfZtkXMnx2pfs4e+5E+U04n/HDwsydue W8jw6LnDdv4CrjaGpfNgZmmu+R4/opymravixq7Oh7JZ848hXijTY3sGfah3a7zB 4I5zzsTZ17GA9x5xr5Qhz+VJGvkODLNDnkKsMMLT7QIPlQUZX9Wqzu55Qu94WQsd gtrf3/RbtyrBZe9XyTgUqhb1uHlbsjlhOxtD68YRBOQ/BGXvU5wFMuwY5gIZxsc= =lH9A -END PGP SIGNATURE-
[gentoo-dev] Over-reliance of Gentoo projects on overlays
Hello, I'd like to raise another issue I've met again recently. Shortly put, some of our projects are relying too much on their overlays. The net result is that some of their packages in the tree are not well-tested, semi-broken and users end up being hurt by that. The major project where this can be seen is science. With no offense intended, but I'm afraid that sometimes the team itself is losing track of what has been committed to the tree and what is in the overlay, and especially which versions are compatible. Another similar project having this problem seems to be lisp. From bug #465864 (which points to many other bugs not fixed in gx86), you can gather: "Anybody who intends to use something lisp-related (like maxima) in Gentoo seriously always uses this overlay. There are too few developers in the common-lisp herd, and the main tree remains neglected for years." (by Andrey Grozin) which shortly shows that in some areas the issues are really serious. Teams, what are the main reasons for keeping that much stuff in overlays? What can be done to avoid it? While I can see the benefits of, say, testing extraordinarily experimental stuff in overlays or keeping there stuff that is not intended to land in gx86 at all (like some custom hacks), I feel like just keeping the newer versions of some packages is more of issue breeder to us. Please remember that most of our users doesn't know those rules. If I am looking for a good mathematics package, I take maxima, though I have almost no idea of lisp except for parentheses. The lisp-related flags are confusing to me and ever worse is the fact that the default choice simply doesn't build. Then I try alternate implementations. Expecting users to grep bugzie or some other kind of pages to find that they are supported to install an overlay to properly use package that is in gx86 is not good. The sole existence and use of overlay is causing the gx86 package and/or its deps to be in increasingly worse shape. If the problem is really manpower, I think you should try to work with proxy-maint. If that's not enough, then we need to find a better solution. In the worst case, we may prefer to move some of the packages out of gx86 and specifically expect all users to use an overlay, consistently. But in this case, we should probably consider redesigning Gentoo to be based more on official or semi-official repositories like Exherbo so that all users would have equal rights. As a last note, I'd like to note that I'm talking about lisp that much because maxima is a recent case where I've seen this. But there were even worse things with science overlay, lapack and blas -- including getting the system into a state where neither gx86, nor science overlay packages work. -- Best regards, Michał Górny signature.asc Description: PGP signature
