path: root/meeting-logs/20140610.txt

[15:02:41] <rich0> roll call: blueness dberkholz dilfridge scarabeus ulm williamh
[15:02:46] <rich0> (or proxies)
[15:03:01] -*- dilfridge here
[15:03:49] -*- ulm here
[15:03:57] <dberkholz> i am still here
[15:04:23] <rich0> blueness, scarabeus, williamh?
[15:05:16] <dilfridge> scarabeus mentioned to me that he couldnt attend and was looking for a proxy
[15:05:21] <ulm> PMS makes people feel uneasy, it seems :)
[15:05:31] <creffett|irssi> williamh probably still missing wrt hardware issues?
[15:05:32] <rich0> creffett|irssi: if you have agreement with scarabeus you can proxy for him.
[15:05:33] <blueness> here
[15:05:40] <rich0> Tend to agree re williamh
[15:05:48] <creffett|irssi> rich0: no agreement, sorry
[15:06:10] <rich0> Ok, then scarabeus, williamh not here, rest present.  Let the PMS fun begin.
[15:06:18] <dilfridge> whee
[15:06:21] <rich0> First topic - items for EAPI6
[15:06:35] <rich0> Per ulm's suggestion we'll use the pools he recommened which I put in the agenda.
[15:06:48] <rich0> First: 1a-c
[15:07:00] <rich0> As found on: https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features
[15:07:13] <rich0> Any commentary before we vote?
[15:07:26] <dilfridge> edocs++, einstalldocs--
[15:07:47] <blueness> rich0, one sec while i refresh my memory on those
[15:07:48] <rich0> Ok, let's chat about all, but we'll break up the vote.
[15:08:22] <rich0> oh, you're just talking about the function name
[15:08:31] <dilfridge> yep.
[15:08:34] <rich0> Just about everything on the list had some level of bikeshedding RE function names/etc.
[15:08:47] <dilfridge> yeah, not important.
[15:08:48] <blueness> ulm, i didn't fully understand  IUSE_EFFECTIVE
[15:08:50] <rich0> I suggest we vote with regard to whether the feature is in/out, and not the specific implemetnation details unless critical.
[15:08:57] <ulm> I don't care about the names
[15:09:15] <rich0> The final PMS change will have to be voted on by the next council before adopted.
[15:09:24] <rich0> So they can do the bikeshedding.  :)
[15:09:30] <ulm> blueness: it's equal to IUSE, plus some flags like "prefix" that are injected from profiles
[15:09:30] <dilfridge> hehe
[15:09:40] <dberkholz> i'm good with 1a-c
[15:09:41] <blueness> ulm, okay
[15:09:46] <dilfridge> vote?
[15:09:47] <blueness> i'm good with those then
[15:09:49] <ulm> blueness: so if you query if a flag can be used, it should be IUSE_EFF
[15:09:51] <rich0> Ok, let's vote.
[15:10:06] -*- blueness yes to 1a-c
[15:10:09] <rich0> The council agrees to include 1a-c in EAPI6
[15:10:09] -*- ulm yes for 1a-c
[15:10:12] -*- rich0 yes
[15:10:14] -*- dilfridge yes for 1a-c
[15:10:34] <dberkholz> yes
[15:10:36] <rich0> Ok
[15:10:39] <rich0> Passed
[15:10:47] <rich0> Next, 2a-f
[15:10:49] <rich0> Discussion?
[15:10:51] <blueness> rich0, wait
[15:10:55] <rich0> (skipping 1d for now)
[15:10:56] <blueness> what about 1d?
[15:10:59] <blueness> oh okay!
[15:11:10] <rich0> (we're picking the fastest stuff to approve first)
[15:11:11] -*- blueness shutsup
[15:11:15] <blueness> yes yes
[15:11:17] <dberkholz> nothing to say re 2a-f
[15:11:27] <ulm> AFAICS 2a-f should all be non-controversial
[15:11:35] <rich0> agree
[15:11:43] <blueness> 2f might be a problem no?
[15:12:01] <ulm> I don't see a problem for 2f
[15:12:04] <blueness> my concern there: will old unpack behavior be changed?
[15:12:19] <rich0> blueness: See comment 11
[15:12:31] <blueness> lookin now to refresh mymemory
[15:12:33] <rich0> That seems like a good compromise
[15:12:35] <blueness> it doesn't help to do these early
[15:12:54] <rich0> Yeah, we're earning our pay on this agenda.  :)
[15:13:16] <blueness> i'm okay with comment 11 three
[15:13:18] <blueness> there
[15:13:25] <dilfridge> actually
[15:13:25] <rich0> Ok, anything else on 2a-f?
[15:13:27] <blueness> i think that's critical for backwards compat
[15:13:30] <dilfridge> ulm: there is a small problem
[15:13:30] -*- blueness done
[15:13:38] <dilfridge>  unpack ./mame.zip
[15:13:43] <dilfridge> and similar usage in the tree
[15:13:53] <dilfridge> what happens there?
[15:14:08] <blueness> it takes the literal path no?
[15:14:23] <rich0> What does portage do today?
[15:14:26] <ulm> dilfridge: path contains a slash, so it's taken as is
[15:14:30] <ulm> no problem there
[15:14:56] <dilfridge> ok
[15:14:57] <rich0> I think we're ok
[15:14:57] <dilfridge> fine
[15:15:01] <blueness> ulm, dilfridge i assume unpack foo.zip and unpack ./foo.zip do the saem thine
[15:15:02] <ulm> so unpack ./mame.zip unpacks in current dir
[15:15:03] <blueness> thing
[15:15:14] <ulm> unpack mame.zip unpacks in DISTDIR
[15:15:18] <rich0> Well, unpack foo.zip would be in DISTDIR
[15:15:25] <blueness> ah yes
[15:15:34] <rich0> I'd assume unpack ./foo.zip would be current dir (likely in $S
[15:15:36] <blueness> so where is the "current dir"
[15:15:41] <blueness> in $S?
[15:15:45] <ulm> rich0: exactly
[15:15:45] <dberkholz> wherever you've switched to
[15:16:16] <blueness> ulm, we may hit a bug there, i suggest we grep the tree
[15:16:18] <rich0> ulm: is that current behavior?  If so then no issues at all
[15:16:18] <dilfridge> anyway we're not changing retroactively
[15:16:30] <blueness> oh never mind, its not retro
[15:16:31] <dilfridge> so who cares if weird stuff is done
[15:16:32] <rich0> That is also true - this is a new EAPI, so fix your builds.
[15:16:47] <rich0> Just get rid of the ./ if it is meant to be DISTDIR
[15:16:55] <rich0> Or add it if you want it to be $S
[15:16:58] <blueness> okay devs will just have to watch it on bumping EAPI's
[15:17:05] <rich0> Ok, good to vote?
[15:17:06] <ulm> it's just the current behaviour for foo.zip and ./foo.zip
[15:17:15] <dilfridge> vote
[15:17:23] <rich0> vote
[15:17:27] -*- rich0 yes for 2a-f
[15:17:31] <ulm> and adds that /some/path/foo.zip is handled too
[15:17:35] -*- dilfridge yes for 2a-f
[15:17:37] -*- ulm yes for 2a-f
[15:17:46] -*- blueness yes
[15:18:11] <rich0> dberkholz ?
[15:18:12] <dberkholz> yes
[15:18:15] <rich0> ok, passed
[15:18:23] <rich0> Next, 3a-b
[15:18:32] <dberkholz> yes x100
[15:18:41] <rich0> Bash stuff.  Discussion?
[15:18:56] <ulm> bash 4.2 is overdue
[15:18:56] <dilfridge> separate votes
[15:19:02] <blueness> i'm very much in favor of 4.2
[15:19:13] <dilfridge> cause 3b looks complicated :P
[15:19:19] <rich0> sure, we can vote separate - let's discuss together since related
[15:19:22] <ulm> and failglob will catch unintentional * in global scope
[15:19:28] <blueness> i had a protage helper bounced because i wrote it using associated arrays in bash only to find out that we're at bash3
[15:19:41] <blueness> dilfridge, i'm glad you asked, i don't understand 3b fully
[15:19:55] <blueness> ulm, can you give us a simple example
[15:20:22] <ulm> blueness: https://bugs.gentoo.org/show_bug.cgi?id=463822 comment 0
[15:20:49] <ulm> with failglob that will error out
[15:21:01] <blueness> so this is the issue -> unless user runs emerge from a directory where the glob matches some actual files and then hell breaks loose
[15:21:14] <ulm> while currently it may or may not work, depending on files in current dir
[15:21:22] <rich0> blueness: yup.  Globbing can potentially change the behavior of the ebuild depending on environment.
[15:21:36] <rich0> with failglob that ebuild will always fail, so issue fixed before commiting.
[15:21:43] <blueness> so what exaclty is nullglob, what context does it live in, is it a bash thingy
[15:22:09] <ulm> nullglob will remove the word
[15:22:23] <ulm> if there are no matches, that is
[15:22:35] <rich0> That might or might not be caught during development.
[15:22:43] <blueness> yeah that's what i'm thinking rich
[15:22:47] <blueness> yeah that's what i'm thinking rich0
[15:23:02] <rich0> It basically under-specifies a dependency, which causes no issues if you have it installed when testing it.
[15:23:05] <blueness> what about the other solution ->  disable globbing completely in global scope and re-enable it in phase scope
[15:23:14] <rich0> blueness: that is the proposal
[15:23:21] <rich0> failglob in global scope
[15:23:25] <rich0> not in function scope
[15:23:43] <dilfridge> yep. I just dont know how much this affects eclasses.
[15:23:59] <rich0> Do we have eclasses globbing in global scope?
[15:24:07] <rich0> It is only an issue if they don't quote.
[15:24:13] <rich0> I'd think the fix is to just add quoting to the eclass.
[15:24:17] <ulm> dilfridge: there's not much going on in global scope in most eclasses
[15:24:21] <rich0> Which is better than leaving them as they are now.
[15:24:43] <ulm> it also won't affect eclasses for existing EAPIs
[15:24:48] <rich0> Also, this only is for EAPI6, so we'll spot that as ebuilds get ported.
[15:24:51] <dilfridge> ulm: could an eclass switch on these features "manually" again if needed?
[15:24:52] <blueness> ulm, there are variables set which could have globs
[15:25:07] <ulm> dilfridge: in global scope? no
[15:25:10] <dilfridge> (I mean, for the code within the eclass)
[15:25:28] <rich0> ulm: agree - how can you glob in global scope - you don't know what $PWD is.
[15:25:32] <ulm> the proposal is to leave things as is in function scope
[15:26:06] <dilfridge> ok I'll stop discussing since I'm not really getting much wiser :]
[15:26:10] <ulm> any unquoted * or [] in global scope qualifies as a bug IMHO
[15:27:08] <blueness> ulm, then have repoman catch it
[15:27:39] <rich0> blueness: that is the alternative, but why not just have bash assert it?
[15:27:52] <rich0> Why try to catch errors if we can prevent them?
[15:28:33] <dilfridge> ok the failglob just introduces an error exit and does not silently change other behaviour?
[15:28:38] <rich0> I don't see there being side-effects here, and it is EAPI6-only anyway.
[15:28:42] <ulm> blueness: I don't see any legitimate use case for globbing in global scope
[15:28:48] <ulm> dilfridge: yes
[15:28:54] <rich0> dilfridge: failglob should make the ebuild fail in all circumstances
[15:29:02] <blueness> ulm, i agree
[15:29:05] <rich0> whether the glob matches or not
[15:29:36] <blueness> okay i'm good with this, ulm convinced me.  there is no reason to glob in the global context, so failglob in global
[15:29:51] <blueness> there *is* a reason to glob in local, so failglob in local functions
[15:29:52] <rich0> I look at it like an assert
[15:29:56] <blueness> yeah
[15:30:04] <blueness> okay i'm good
[15:30:11] <rich0> Ok, vote?
[15:30:18] <ulm> yes, please
[15:30:23] -*- blueness thanks ulm for patiently explaining
[15:30:42] <rich0> vote: 3a-b (but 3b failglob in global scope only)
[15:30:50] -*- rich0 yes
[15:30:55] <dberkholz> still incredibly huge fan of 3a (finally), and 3b is fine too
[15:31:01] -*- dilfridge yes 3a-b
[15:31:08] -*- ulm yes for 3a-b
[15:31:17] -*- blueness yes
[15:31:21] <rich0> ok, passed :)
[15:31:31] <rich0> Now we have individuals...
[15:31:34] <rich0> 1d
[15:31:48] <rich0> PATCHES support in default src_prepare bug #463692
[15:31:50] <willikins> rich0: https://bugs.gentoo.org/463692 "[Future EAPI] Provide PATCHES array support in default phase of src_prepare"; Gentoo Hosted Projects, PMS/EAPI; CONF; scarabeus:pms-bugs
[15:32:18] <rich0> I'm fine with it.  Discussion?
[15:32:29] <ulm> this depends on 4a
[15:32:30] <dilfridge> ok let me say that the path-level automagic can lead to annoying bugs
[15:32:44] <rich0> Do we want to hit 4a first?
[15:32:48] <dilfridge> yep
[15:32:53] <ulm> rich0: makes more sense
[15:32:56] <blueness> rich0, i'm worried about the order that hte patches are done
[15:33:00] <rich0> ok let's do 4a first. agree
[15:33:05] <dberkholz> k
[15:33:12] <ulm> blueness: lexicographic order in C locale
[15:33:18] <rich0> Patch applying function in package manager bug #463768
[15:33:20] <willikins> rich0: https://bugs.gentoo.org/463768 "[Future EAPI] Introduce patch applying function"; Gentoo Hosted Projects, PMS/EAPI; CONF; mgorny:pms-bugs
[15:33:31] <rich0> I put my two cents on the list.
[15:33:47] <rich0> I suggest defaulting to -p1, but allowing the specification of -p#, but no auto-detection
[15:33:57] <ulm> rich0: +1
[15:34:15] <rich0> and directories in lexical order
[15:34:18] <blueness> yeah auto-detection bit me once
[15:34:29] <rich0> Basically comment 32
[15:34:29] <dilfridge> rich0: +1
[15:34:43] <ulm> rich0: however, if you need anything other than -p1 you'll have to call the function explicitly
[15:34:57] <blueness> rich0, are you sure aobut the lexi order?  because if it a bash array we can control the oder by the order in which the patches are presetned
[15:35:00] <ulm> and then you could call epatch instead, as well
[15:35:16] <dberkholz> i don't particularly like making it more difficult or making more work for devs
[15:35:24] <dilfridge> blueness: that's just if the array contains a directory name
[15:35:25] <blueness> it might be annoying to have to rename patches to get the order right
[15:35:33] <ulm> blueness: lexicographical for patches inside some dir
[15:35:39] <dberkholz> blueness: lexi order is consistent with epatch bulk patching
[15:35:49] <rich0> Yeah - just for a directory.
[15:35:50] <ulm> otherwise, the order they are specified in
[15:35:57] <blueness> dilfridge, got it
[15:36:04] <rich0> If epatch took multiple arguments then obviously do them however passed.
[15:36:09] <rich0> That isn't in the bug though.
[15:36:25] <rich0> Actually, it says "files" so I guess that means multiple args.
[15:36:29] <blueness> dilfridge, ulm so a user can force an order by avoiding using a dir
[15:36:38] <dilfridge> yes, as I see it.
[15:36:46] <blueness> i can live with that
[15:36:55] <rich0> blueness: yup, or they could just glob in a dir and manipulate the list before passing or whatever
[15:37:00] <dilfridge> and all patches in a specified directory need to have the same path depth
[15:37:07] <rich0> dilfridge: ++
[15:37:16] <ulm> I would advise against to much bikeshedding at this point
[15:37:17] <dilfridge> now,
[15:37:18] <ulm> let's first see how the implemetation goes, and then we can reconsider
[15:37:21] <rich0> ulm: agree
[15:37:24] <dilfridge> agreed
[15:37:36] <rich0> I just want to keep it simple so that this isn't a big production to build
[15:37:44] <rich0> This isn't the final PMS
[15:38:01] <rich0> Ok, so then here is my proposal: 
[15:38:03] <dberkholz> i'm not particularly convinced this should be in pms at all
[15:38:07] <blueness> (implimentation and design simplicity are inversely proportional)
[15:38:35] <dberkholz> duplicating something that works pretty well with a less functional version that's harder to change just doesn't seem like a great idea
[15:38:49] <blueness> its in eutils.eclass no?
[15:39:05] <ulm> epatch, yes
[15:39:12] <rich0> To summarise again what has been discussed so far, the patch applying
[15:39:12] <rich0> function should support the following features:
[15:39:12] <rich0>   - regular patch files - directories, with patches applied in lexical
[15:39:12] <rich0>   order of their filenames, only files named *.diff and *.patch - either
[15:39:12] <rich0>   way a) defaults to -p1 b) allows override to -p#
[15:39:22] <ulm> but if we want user patches we need it in the package manager
[15:39:48] <rich0> ugh - ugly
[15:39:48] <blueness> ulm, we have user patches now via /etc/portage/patches
[15:40:19] <ulm> blueness: which need eutils to be applied
[15:41:04] <rich0> I think the goal here is to enable PATCHES support and user-patches.
[15:41:11] <blueness> ulm, ah ues via user_patch
[15:41:37] <blueness> hmmm ... so is it good to globally add user_patch??
[15:41:57] <blueness> s/ues/yes/
[15:41:58] <rich0> blueness: well, that is also on our agenda.
[15:42:14] <rich0> If we want to discuss all patch-related items before voting I don't have an issue with it.
[15:43:19] <rich0> I'm in favor of 4a, 1d, and 4b, so I don't have an issue with 4a.  But, 4a might not make much sense without 1d and 4b.
[15:43:52] <rich0> And 4b probably involves some bikeshedding.
[15:43:58] <ulm> rich0: right, so maybe we should vote on 1d and 4b only
[15:44:12] <ulm> and 4a is implied if one of them is accepted
[15:44:51] <rich0> Let's move on then.
[15:44:55] <rich0> 1d
[15:45:26] <rich0> PATCHES support in default src_prepare
[15:45:26] <rich0> bug #463692
[15:45:28] <willikins> rich0: https://bugs.gentoo.org/463692 "[Future EAPI] Provide PATCHES array support in default phase of src_prepare"; Gentoo Hosted Projects, PMS/EAPI; CONF; scarabeus:pms-bugs
[15:45:36] <dberkholz> i'd prefer to see more things move out into eclasses from the core PM rather than vice versa. so i'm against it.
[15:45:51] <blueness> i think i'm with dberkholz here
[15:46:20] <ulm> 1d is in line with the recent trend to specify things via variables
[15:46:26] <rich0> I actually am looking at it from the standpoint that the more you move into environment the better.
[15:46:29] <ulm> instead of functional coding
[15:46:31] <blueness> i like the idea of 4b - user_patches, but not of duplicating eutils.eclass functionality
[15:46:39] <dilfridge> that doesnt make sense if we want to globally accept user patches
[15:46:58] <rich0> Look at systemd units vs openrc scripts.
[15:47:01] -*- rich0 ducks
[15:47:06] <dberkholz> ulm: yeah, which i also dislike. but PATCHES is so generally accepted that i don't really see it as a change there.
[15:47:13] <rich0> Tell the PM what to do, not how to do it.
[15:48:23] <ulm> I've nothing more to say about 1d
[15:48:43] <rich0> Ok, do we want to discuss further?
[15:49:00] <rich0> I'm all for "less side-effects" so I'm generally in favor of 1d.
[15:50:32] <rich0> Ok, I'm not hearing more discussion
[15:50:35] <rich0> Do we just vote?
[15:50:40] <dberkholz> sure
[15:50:49] <rich0> Ok, let's vote for 1d alone
[15:50:51] -*- rich0 yes
[15:50:55] -*- ulm 1d abstain
[15:50:58] <dberkholz> no
[15:51:02] -*- dilfridge yes
[15:51:11] -*- blueness no
[15:51:22] <rich0> Ok, that leaves us 2-2 with one abstain
[15:51:32] <rich0> ulm, care to tiebreak, or else it is defeated.
[15:51:51] <ulm> rich0: let it be defeated then
[15:51:56] <rich0> ok, 1d is out.
[15:52:08] <rich0> 4b - user patches
[15:52:22] <rich0> This one might get some bikeshedding
[15:52:29] <rich0> I'm in favor of it, though there are a few ways it could go
[15:52:33] <dberkholz> fwiw i've gotta run in 10 minutes, but i'll leave my votes behind.
[15:52:49] <rich0> Ok, before we discuss
[15:53:01] <rich0> Do we want to plan on same bat time, same bat channel next week?
[15:53:19] <ulm> rich0: fine with me
[15:53:23] <dilfridge> yeah
[15:53:28] <dberkholz> wfm
[15:53:42] <rich0> Ok, then let's discuss until 4, and then we can avoid further votes and let this die out after 4b
[15:53:52] <blueness> i'm okay with jun 17 @ this time
[15:54:25] <rich0> So, I'm fine with either having ebuilds call euserpatch or whatever in src_prepare(), or adding a new phase function to apply user patches.
[15:54:51] <rich0> But if we do the latter we need a prepare, userpatch, configure step
[15:54:54] <dilfridge> in principle I like the concept, but getting it "right" is not easy
[15:55:12] <rich0> I think that calling euserpatch is the lesser evil, despite what I said earlier about what vs how.
[15:55:45] <rich0> Or apply_user_patches or whatever
[15:55:58] <ulm> I'd be opposed against any additional phase functions
[15:56:10] <ulm> the feature isn't important enough for that
[15:56:19] <rich0> ulm: I don't like the additional functions either - not my first preference.
[15:56:29] <rich0> I think this feature actually is important.  It is VERY useful.
[15:56:30] <dberkholz> i just added an entry to the google calendar
[15:56:40] <rich0> However, I'm not sure adding multiple phases just to implement it is necessary.
[15:56:57] <ulm> _if_ we accept it, just add it to default_src_prepare, and have ebuilds/eclasses call it from src_prepare
[15:57:05] <rich0> ulm: ++
[15:57:19] <rich0> I think that is the simplest solution, as much as some might complain about the need to call it
[15:57:43] <ulm> rich0: more will complain about automatic calling that can't be disabled
[15:58:00] <dberkholz> this still means we're adding a weird custom patch function to the PM, which i dislike.
[15:58:00] <rich0> I don't patch stuff often, but when I do it is WAY nicer to have user-patches than to hack away at things with the ebuild command.
[15:58:06] <ulm> e.g. in virtuals you won't want it
[15:58:20] <rich0> What is "custom" about it?
[15:58:33] <rich0> ulm: good point
[15:58:46] <dberkholz> is the PM going to call out to epatch in the eclass?
[15:58:57] <blueness> dberkholz, i don't get your reasoning, rich0 said it for me "it is WAY nicer to have user-patches than to hack away at things with the ebuild command"
[15:59:01] <rich0> dberkholz: probably not - we'd need 4a to do it.
[15:59:05] <dilfridge> well, I definitely would not want to add the full current epatch to the pm, but a simpler variant should be ok, since patching is pretty central to our stuff
[15:59:09] <dberkholz> and 4a is what i hate
[15:59:19] <rich0> user patches would be -p1 only
[15:59:25] <_AxS_> ulm: rich0: if epatch_user's new equiv is added to default src_prepare on its own, what about the case where build systems get patched and need to be regen'ed ?  do we leave that to the end-user to figure out or will this function need smarts in order to either (a) accomodate or (b) warn?
[15:59:45] <dilfridge> the PATCHES array is what everyone working with kde / cmake loooves
[15:59:48] <dberkholz> this whole "let's add a worse, less flexible patch function that's harder to change and then keep a more functional duplicate version in the tree" just seems awful
[16:00:13] <blueness> dberkholz, hmmm ...
[16:00:21] <blueness> rich0, can we table this one for next week
[16:00:27] <ulm> _AxS_: there's no way of adding eautoreconf to an ebuild where it's not provided already
[16:00:28] <rich0> dberkholz: how else would you propose doing user patches, or do we just not do it?
[16:00:37] <rich0> blueness: we're going to table voting regardless
[16:00:46] <blueness> rich0, okay, so just discussion
[16:00:48] <rich0> So we can discuss a bit longer or break as we see fit
[16:00:52] <ulm> _AxS_: unless you want to inherit autotools everywhere
[16:00:55] -*- blueness needs time to think
[16:01:18] <rich0> We're at 4 - so I'll officially call the meeting, to convene next week.  We can continue to chat until we get tired of it, and discuss on lists/etc as necessary before next week.
[16:01:19] <_AxS_> ulm: true, and i expect logic to determine if configure.ac / any-other-build-system-file-needing-preparation is modified would be overly complicated too, to trigger an ewarn/eerror/etc
[16:01:29] <rich0> Err, 20:00
[16:01:32] <dberkholz> rich0: if that's the cost, i don't want to pay it
[16:01:48] <dberkholz> one option i keep toying with is whether we could move default phase functions out into the tree
[16:02:01] <ulm> well, there is a reason why this was rejected from EAPI 5 already ;)
[16:02:16] <dberkholz> but not sure how feasible it is, and obviously it means anyone not based on gentoo-x86 would need a copy
[16:03:41] <dberkholz> anyway, gotta run.
[16:03:45] <_AxS_> dberkholz: ?  you mean, revive base.eclass and implement there?
[16:04:05] <rich0> dberkholz: honestly, in my ideal word you'd be able to express an ebuild without anything other than a variable assignment, or in xml/whatever.  We'd never get that far, but that is the direction I'd prefer.
[16:04:11] <rich0> More declarative, less imperitive.
[16:04:32] <rich0> Ok, all who want to keep chatting are welcome to do so - open floor on this.
[16:04:44] <rich0> To the rest, thanks - we covered a lot!
[16:04:58] <rich0> I'll take care of log/summary, including subsequent discussion.
[16:05:33] <dilfridge> Cheers for cheering, err chairing :)
[16:05:42] <rich0> I might start a thread on the whole eclass vs PMS issue.  That alone is worth some input.
[16:06:11] <ulm> rich0: ebuilds in xml? I thought we were past that mistake
[16:06:21] <rich0> ulm: has it been done?
[16:06:26] <ulm> it was called zynot
[16:06:42] <ulm> google for it ;)
[16:07:05] <rich0> I didn't realize they used xml packages.
[16:07:43] <rich0> I posted ages back (during the whole EAPI extension debate) that I do think we should be able to have a way to get rid of the ebuild==bash thing, but I'm not in any rush to get there.
[16:08:07] <rich0> CGI for the PM.  :)
[16:08:41] <rich0> emerge <whatever this webservice sends you>
[16:09:02] <ulm> that's called an app store ;)
[16:09:45] <rich0> So, anything else to discuss here?  I think a lot of this comes down to philosophy.  I just see user_patches as incredibly useful and really a potential distinctive feature for a source-based distro.
[16:10:01] <rich0> If I were selling Gentoo, it would be something I'd want on my features list.
[16:10:19] <blueness> rich0, what about next years election, is someone on that?
[16:10:27] <rich0> I can't see floating this on gentoo-user and getting a lot of, "no, I don't care if Gentoo makes it easier for me to patch stuff without forking an ebuild."
[16:10:40] <rich0> blueness: I'll ping them.  I know they know, but somebody has to do it.
[16:10:51] <rich0> It is time to start nominations.
[16:11:02] <blueness> rich0, the user_epatch is more than just users patching
[16:11:18] <blueness> there are lots of patches for uclibc and musl that are unlikely to get into the tree
[16:11:25] <rich0> jmbsvicetto: ^^^
[16:11:36] <blueness> so i put them in /etc/portage/patches during stage builds
[16:11:51] <blueness> not uclibc anymore which is purely gentoo tree now after some work
[16:12:11] <rich0> blueness: that makes me wonder if official patchsets controlled by something USE-like might be a later extension of this
[16:12:30] <blueness> yeah i can see that
[16:12:40] <rich0> openssh has USE=hpn by default
[16:12:56] <rich0> Might be better to use USE for enable/disable/etc and something else for patches.
[16:14:02] <_AxS_> rich0: i agree with you that user_patches is useful, but we need to make it work for all cases for it to continue to be useful.  if the patch touches configure.ac we can't leave users hanging to figure out why their patch didn't work properly, and end up having to overlay the ebuild anyhow...
[16:14:37] <_AxS_> *OR*, we do have that, and make it very clear that if a patch modifies the build system then it need to result in overlaying.  and e(qa)warn appropriately.
[16:14:46] <rich0> Good point.
[16:14:57] <rich0> We need to either not guarantee that you can patch the build system.
[16:15:13] <rich0> Or we need to specify that ebuild authors always have to reconfigure the build system if appropriate.
[16:15:24] <rich0> I don't see how we can do that in the default function, since not all is autotools/etc.
[16:15:32] -*- _AxS_ is leaning to the latter, since a build system patch that adds features will probably need some src_configure additions too
[16:16:12] <rich0> Maybe we should just rule out build-system changes?
[16:16:30] <rich0> If I were doing agile I'd say that we'd do that in the next sprint.  :)
[16:16:50] <rich0> How often do people really want to change the build system?
[16:16:59] <rich0> I can't really see using user patches for huge patch sets.
[16:17:17] <rich0> If you're going to fork upstream, just fork it.
[16:17:39] <_AxS_> rich0: well, most of my patches end up being build system related, but as a dev i guess that's where i tend to look to make changes...
[16:19:36] <rich0> true, I never really thought of this as a way to test out ebuild fixes/etc.
[16:19:44] <rich0> But as a dev you can always fix the ebuild to reconfigure/etc.
[16:20:18] <rich0> I think this feature needs a bit more work to lay out expectations.
[16:20:46] <rich0> It isn't enough to tell everybody to call the new function.  You have to lay out what they need to accomodate in terms of patch impact.
[16:21:21] -*- _AxS_ nods ..  we already have epatch_user in place and a lot of packages -have- adopted that.  but to get full coverage....
[16:22:17] <rich0> The question is whether all ebuilds that call apply_user_patches or whatever re-configure after doing so.
[16:22:26] <ulm> epatch_user is a good example for a quick hack that has outgrown its purpose
[16:22:28] <rich0> If the package didn't otherwise need to fix autotools, then it might lack that step.
[16:22:47] <ulm> it was just a hack, added to eutils without much design
[16:22:51] <rich0> ulm: agree, but the fact that it is so darn useful makes me want to come up with the real solution
[16:23:46] <ulm> there cannot be a perfect solution
[16:24:03] <ulm> some patches inevitably require other changes to the ebuild
[16:24:10] <rich0> ulm: the story of the project I'm working on when I'm not in council meetings...
[16:24:33] <ulm> e.g. addition of features will often require additional dependencies
[16:24:37] <ulm> or USE flags
[16:26:23] <ulm> brb
[16:33:17] <rich0> ulm: I need disappear myself.  Let's bikeshed this on-list and see if we can get it to a workable state.  I'd be interested in what features the community wants.  No need to over-do this.