Discussion in #gentoo-pms from 2016-06-19

gentoo-pms.log (text/plain), 5.16 KB, created by Ulrich Müller on 2017-02-23 15:53:21 UTC

[18:48:25] <ulm> mgorny: I've started to look at per-package eclasses
[18:48:46] <ulm> I think they should pretty much work like normal eclasses
[18:49:07] <ulm> several open questions remain, though
[18:50:54] <ulm> 1. where to store them? the glep draft by mabi and antarus suggests the package dir
[18:51:51] <ulm> and I guess that's just fine, given that the typical number of eclasses for a package will be just one
[18:51:54] <ulm> (or zero)
[18:53:17] <ulm> FILESDIR is sort of excluded, since we don't want to access that from global scope
[18:55:23] <ulm> one could think about an "eclass" dir, but it's not very useful with typically only one file in it
[18:55:30] <ulm> or very few
[18:56:35] <ulm> 2. I suppose the ECLASS variable would get assigned to ${CATEGORY}/${PN}/<eclassname>?
[18:56:53] <ulm> same for INHERITED
[18:58:26] <ulm> 3. the glep suggests a "pkg-inherit" command, but I think that "inherit -p" might be more systematic
[18:58:43] <ulm> or "inherit ${CATEGORY}/${PN}/<eclassname>"
[18:59:47] <ulm> where ${CATEGORY}/${PN} is pretty much redundant though, since there is only one value allowed for it, namely the package itself
[19:00:03] <ulm> so maybe "inherit ./<eclassname>" :)
[19:00:08] <mgorny> honestly? i don't like that idea at all
[19:00:18] <mgorny> it's another workaround for proper ebuild workflow
[19:00:30] <ulm> what? the whole per-package eclasses?
[...]
[19:00:35] <mgorny> yes
[19:01:49] <ulm> it's sort of a compromise, otherwise I think we won't get rid of eblits
[19:02:24] <mgorny> i would start earlier then
[19:02:31] <mgorny> 1. do we want multiple eclasses per package?
[19:02:44] <mgorny> 2. how special are they supposed to be?
[19:03:02] <ulm> yeah, you may want an -r1 at some point
[19:03:43] <ulm> otherwise people will update in-place and it will affect stable
[19:04:59] <ulm> the question is of course if the eclasses for the few packages that need them couldn't live in the regular eclass dir
[19:05:37] <ulm> sort of overkill to do this for only 10 packages
[19:05:47] <mgorny> yes, exactly my point
[19:06:01] <mgorny> we already do USE_EXPANDs globally for single packages
[19:06:08] <mgorny> we could live with eclasses for single packages...
[19:06:55] <mgorny> alternatively, i would go for having $pkgdir/eclass/ which gets precedence over $repodir/eclass, and regular procedure
[19:07:08] <mgorny> i.e. smallest effort needed
[19:07:23] <ulm> is scanning the tree
[19:07:55] <ulm> what?!!
[19:08:00] <ulm> only four packages
[19:08:03] <ulm> dev-lang/perl sys-devel/autoconf sys-kernel/mips-sources sys-libs/glibc
[19:08:21] <mgorny> obviously
[19:08:22] <ulm> ok, these could all live in eclass I think
[19:08:38] <ulm> how many of these are maintained by vapier?
[19:08:47] <mgorny> 2 at least
[19:08:53] <mgorny> dunno about mips-sources
[19:08:59] <ulm> autoconf and gcc are the obvious ones
[19:09:03] <mgorny> and perl... is kinda ancient, so vapier could be there too
[19:09:39] <mgorny> also, dev-lang/perl: Go back from eblits to a monolithic ebuild
[19:10:52] <ulm> commit 5fcd2a8e3cc5cff32e04fe05eca046765aba2589
[19:10:52] <ulm> Author: Joshua Kinard <[e-mail]>
[19:10:53] <ulm> Date:   Mon Mar 16 06:39:10 2009 +0000
[19:11:03] <ulm> ^^ that's it for mips-sources
[19:11:51] <mgorny> and tove for perl
[...]
[19:13:08] <mgorny> so... RESO/WONTFIX, use damn eclasses?
[19:14:26] <ulm> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/gleps/glep-XX.txt?view=markup#l23
[19:14:42] <ulm> reading it again, that rationale isn't really convincing
[19:15:02] <ulm> "The sheer number of eclasses makes it hard for old and new developers to quickly find the eclass they are looking for."
[19:15:36] <mgorny> ;-D
[19:15:49] <mgorny> is antarus still around?
[19:16:11] <ulm> also Manifest signing isn't an argument, because that has to be solved for the eclass dir
[19:16:24] <ulm> yep, he is
[19:17:03] <ulm> "The data show that the number of eclasses will be reduced by three (mysql, php, and nvidia-drivers.) This is not a compelling argument."
[19:17:17] <mgorny> lol?
[19:17:32] <mgorny> i didn't know nvidia-drivers use an eclass
[19:17:55] <ulm> there is nvidia-driver.eclass
[19:18:10] <ulm> why? :)
[19:20:02] <mgorny> because jer?
[19:20:22] <ulm> I guess they didn't want these large tables of numbers in every ebuild
[19:22:11] <mgorny> well, i guess that makes sense
[19:22:22] <mgorny> as long as we're talking about keeping utility stuff in eclasses rather than moving the whole ebuild there
[19:23:20] <ulm> anyway, I really shouldn't be championing per-package eclasses
[19:23:40] <ulm> if someone comes up with valid arguments then it can be discussed
[19:34:41] <mgorny> do you agree on WONTFIX-ing it with explanation and preventing people from using it as argument to keep eblits?
[19:43:23] <ulm> mgorny: have I missed that there is a bug, or do you mean WONTFIX in metaphorical sense?
[19:43:41] <mgorny> lemme check
[19:43:47] <mgorny> hmm, looks like there isn't
[19:44:01] <mgorny> then let's file bugs about killing eblits
[19:44:12] <ulm> there was none blocking the future-eapi bug
[19:44:36] <ulm> but feel free to add a nasty comment in https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_7_tentative_features
[19:44:47] <ulm> bottommost item