16:00:49 #startmeeting fpc 16:00:49 Meeting started Thu Aug 25 16:00:49 2016 UTC. The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:49 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:49 The meeting name has been set to 'fpc' 16:00:50 #meetingname fpc 16:00:50 The meeting name has been set to 'fpc' 16:00:50 #topic Roll Call 16:01:15 Hi 16:01:20 #chair mboddu 16:01:20 Current chairs: geppetto mboddu 16:01:22 hello 16:01:31 #unchair mboddu 16:01:31 Current chairs: geppetto 16:01:36 #chair mbooth 16:01:36 Current chairs: geppetto mbooth 16:01:40 #chair orionp 16:01:40 Current chairs: geppetto mbooth orionp 16:01:43 #chair tibbs 16:01:43 Current chairs: geppetto mbooth orionp tibbs 16:01:55 tibbs: Here's your terrible day ping :) 16:02:17 Thanks. 16:02:58 So this week's lesson is that you can't trust RHEL/Centos 7 to properly serve NFS. 16:03:06 :-o 16:03:22 * limburgher here 16:04:00 #chair limburgher 16:04:01 Current chairs: geppetto limburgher mbooth orionp tibbs 16:04:11 * racor is here, but I guess I need to leave early, today 16:04:30 #chair racor 16:04:30 Current chairs: geppetto limburgher mbooth orionp racor tibbs 16:04:36 #chair Rathann 16:04:36 Current chairs: Rathann geppetto limburgher mbooth orionp racor tibbs 16:04:50 #topic Schedule 16:04:52 https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/S2JZSCRAQIC5CSKLY55BLIE37R44NRF4/ 16:05:04 #topic #635 FC Automatic Provides for Python RPM Packages 16:05:04 hi 16:05:09 .fpc 635 16:05:10 geppetto: #635 (FC Automatic Provides for Python RPM Packages: Accompanying change of Python packaging guidelines) – fpc - https://fedorahosted.org/fpc/ticket/635 16:06:35 I believe the diff is https://fedoraproject.org/w/index.php?title=User%3ATorsava%2FPackagingDrafts%2FPython&diff=468811&oldid=466988 16:07:45 Which is... a lot. 16:08:07 hello :) 16:08:15 Might be too verbose, I don't know. 16:08:29 But people really, really want the python guideline document to be massive, I guess. 16:08:34 * limburgher burns finger on hot scroll wheel 16:08:38 Why does python have to be so terrible? 16:10:00 because it's the least terrible of the scripting languages ... so it has to catch up 16:10:18 heh 16:10:22 it's not so bad 16:10:34 nah ... 16:10:54 i for one appreciate the detail. 16:10:55 I. . . 16:11:24 I mean, why do we need things that happen automaticly in the packaging guidelines... What action does the packager need to take? 16:11:39 The detail isn't great when people can't find what they need because the document is so large. 16:11:54 mbooth: it's telling the package how they can use the pythonX_requires and pythonX_buildrequires macros. 16:12:06 Now, I freely admit that the python guidelines have never really been great for that. Perhaps before python3 they weren't too bad. 16:12:24 Right, so like is this reflected in a change to the example spec? 16:13:14 The example spec is a whole separate issue. 16:13:40 It's actually not a great example. One proposal was to remove it entirely and just link to some page somewhere that the Red Hat python group maintains. 16:13:57 I don't particularly like that, but.... 16:14:32 Some page inside the Guidelines or a Only-RH-Can-Edit-Me page? 16:14:39 There's sort of a theme I'm seeing of moving python guideline stuff out from under FPC. 16:14:53 And just sending us "now that this is implemented, update the guidelines to match". 16:15:30 This particular change isn't really objectionable to me but we need to be on the lookout for another SCL-like incident. 16:15:31 adamw: This is way more complex than it needs to be 16:15:54 Why is a macro even necessary to say simply "Requires: python3dist(virtualenv)" 16:16:04 * Rathann notes that rpmdev-newspec --type python doesn't use the current macros 16:16:16 Rathann: I don't think it ever gets updated. 16:16:25 mbooth: it isn't, you can say that directly 16:16:38 Rathann: Exactly 16:16:39 Last time I tried, the maintainer didn't want to generate things that didn't work verbatim on EL5 or something. 16:16:50 mbooth: I guess it's a convenience. 16:16:59 Use it when it saves you effort, don't if it doesn't. 16:17:15 I don't mind things like that; I have a whole pile of utility macros that do this. 16:17:24 it enables sed conversion of existing (Build)Requires 16:17:27 But it's not necessary to describe it in that much detail, I think. 16:17:36 at least that's my take on it 16:17:41 tibbs: But I don't see that it has any convenience value -- you still need to know a python version and a module name -- what does it save you? 16:17:57 Can't answer that one. 16:18:21 Look, can folks who have time take a pass over this and suggest cleanups/simplifications? 16:18:45 At least the macro list on the actual page is hidden by default.... 16:18:55 Yeh 16:19:06 Also the 3rd example just before the macros is a bit silly 16:19:16 Yeah. 16:19:46 We have auto-provides in Java land too, there is no need for all this complexity 16:19:47 hm do I understand correctly that the Requires: for python packages are still not automatically generated? 16:19:56 Rathann: You are correct. 16:19:59 :( 16:20:12 a half-baked solution, then 16:20:12 That requires parsing and such. Perl does it and gets it wrong enough to be annoying. 16:20:22 Well, you have to have one side before you can have the other. 16:20:42 I would guess that's in the plan. 16:20:46 right 16:21:44 ok, I'll take a stab at simplifying this page 16:21:54 mbooth: Do you parse the source to do it? 16:22:02 though I can't promise I'll be able to do it before next meeting 16:22:03 mbooth: In java land? 16:22:38 geppetto: We parse maven metadata 16:22:50 But that's irrelevant 16:22:55 maven metadata is machine-readable 16:22:59 It's like even having separate macros for Rs and BRs ... 16:23:05 as it's XML IIRC 16:23:22 If it were entirely up to me, I would write a macro that can parse the python metadata and generate the relevant parts of the spec file magically. 16:23:29 mbooth: yeah, that doesn't make much sense 16:23:30 Why not just have one macro and require user to put R: %{macro} or BR: %{macro} 16:23:34 If it works for even half of the packages, that would be a huge bonus. 16:23:38 mbooth: +1 to that 16:24:09 Note that the python folks are talking about making the specfile an immutable generated artefact of some generator. 16:24:18 Which I would in general oppose. 16:24:43 huh 16:25:34 I'm not against generated specfiles as long as they remain readable and maintainable 16:25:47 the point of the macro, as i see it, is to make it so you don't have to remember the rules of normalizing the module name. 16:25:49 But... they wouldn't be maintainable at all. 16:26:00 i.e. what non-alphanumeric characters remain, which are dropped, what to do with capital letters and so on. 16:26:05 adamw: Sure, it's a convenience, which is fine. 16:26:18 you can just use the name as it is in pypi, and the module handles converting it to fedora's package naming policy. 16:26:59 adamw: which module? 16:27:10 er, i mean, macro. 16:27:13 I think he means the innards of the macro definition. 16:27:21 I thought we were talking about macros which actually do the opposite... 16:27:54 Rathann: Note that if you tried to maintain one of those specs, your changes would just be overwritten. They wouldn't want them to be edited. 16:28:25 tibbs: ah, that might be annoying 16:28:31 I've long considered the idea of having the specfile be an intermediate language which some other tool generates. 16:28:35 what would generate them, then? 16:28:40 adamw: So the guidelines should say "Do BR: python3dist(pypi_module_name_here)" 16:28:41 aren't you getting a long way off track at this point? 16:28:43 py2rpm or something like that. 16:28:50 mbooth: huh? 16:28:54 Why are extra macros even necessary? 16:29:06 mbooth: because if you use the pypi module name it might be wrong. 16:29:09 mbooth: I think the point is that they aren't necessary, but they're useful. 16:29:22 mbooth: if the pypi module name is FooBar___123 or something. 16:29:26 adamw: But the auto-provides should be generated correctly... 16:29:42 adamw: the proposed guidelines says "standardized name (i.e. dist name, name on PyPI)" 16:29:56 I, too, understand it as pypi name 16:30:23 you're not reading far enough. 16:30:41 it then says "then automatically creates two Provides: tags in the following format:" , and the format says "CANONICAL_STANDARDIZED_NAME" 16:31:03 then it defines what it means by 'canonical standardized name': "between the parentheses is the name of the software in a '''canonical format''' used by Python tools and services such as setuptools, pip and PyPI. The canonical name is obtained by switching the standardized name to lower case and converting all runs of non-alphanumeric characters to single “-” characters." 16:31:17 I don't think we would oppose something that's useful. It just needs a cleaned up description. It just doesn't need that much detail. 16:31:43 Does anyone oppose the basics of what's there, outside of excessive verbosity? 16:32:01 I'm +1 in general, but -1 as is 16:32:02 so if the package's .egg-info says it provides, say, MyAwesomeClass$$$ , the provide would be python3distmyawesomeclass- 16:32:36 adamw: you missed the crackets? 16:32:40 brackets, even 16:32:45 adamw: my brain doesn't parse the difference between "standardized name", "canonical format" and "canonical standardized name" 16:32:49 oh yeah, i thought they were not really there. but anyhow 16:32:59 it's all the same to me, but apparently not to the author of this text 16:33:00 Rathann: that's why the text tells you exactly what they all are... 16:33:07 Right, I'm not ready to +1 but I don't see any issues with this in general. When we get some proper example specs done, those macros can be showcased there. I'm not going to object to the fact that they didn't update the existing bad example. 16:33:17 adamw: That requires a different macro for BRs and Rs? 16:33:20 use different terms, then, not confusingly similar ones 16:33:27 I am -1 16:33:29 mbooth: not sure why that is. 16:33:40 The implementation seems ill-thought out as is 16:33:51 Rathann: i dunno, i had no problem at all reading it first time through. as an actual person who packages python stuff. 16:34:07 adamw: I maintain a number of python packages as well 16:35:08 I'm not sure why we need requires/buildrequires and not have everyone just use an python_dist_name 16:35:09 And I don't think the blurb about auto-provides needs to exist if the packager does not need to know about the CANONICAL_STANDARDIZED_NAME 16:35:13 But I think I'm +1 anyway 16:35:19 mbooth: it does also say "you can use the %{python_dist_name} macro that only transforms any ''standardized name'' to a ''canonical format''." 16:35:41 adamw: Then that's the only macro that a packager needs to know about 16:35:51 not really, no. 16:36:00 I'd call one "pypi name" and the other "standardized name" 16:36:10 Cut the rest of the fat 16:36:10 that's sufficiently different to avoid confusion 16:36:44 upstream name, might be better than pypi 16:36:53 but meh. 16:37:07 geppetto: what if upstream project name is different than what's on pypi? 16:37:53 does everything have to be on pypi? 16:38:47 so let me get this straight: %{python2_requires foo} is actually equivalent to Requires: python2.7dist(%{python_dist_name foo})? 16:39:46 Sorry folks, as expected, I just received a call and need to leave now. 16:40:00 Rathann: That's how I read it, which seems like "%{python2_requires foo}" macro is totally unnecessary to me 16:40:29 You save a couple a keystrokes, with the additional mental overhead of having to know more macros :-/ 16:40:45 it's not totally unnecessary 16:40:51 mbooth: I totally agree 16:41:04 because it allows you to handle different python versions on different distros. 16:41:16 i.e., it deals with the EPEL problem. 16:41:48 at least, i think that's what it's for 16:42:01 adamw: Why can't it be less specific, say "python2dist" 16:42:10 Like the python3dist one is? 16:42:16 yeah, but one macro should be enough to canonicalize the name and insert the python version 16:42:18 i dunno, but instead of assuming people are idiots, maybe you could ask them? 16:42:39 adamw: I just asked you ;-) 16:42:40 I don't think anyone's assuming that people are idiots. 16:42:56 Requires: %{pythondist 2 foo} would be much easier to use IMO 16:43:03 mbooth: i didn't write it, i just stopped by in case you come to my ticket later 16:43:06 but i kinda got sucked in 16:43:07 mbooth: Can you summarize the issues you see and try to suggest what you think it should look like? 16:43:11 BuildRequires: %{pythondist 3 bar} 16:43:13 etc. 16:43:28 We can change the macros if we need to. Or at least, we'd better damn well be able to do so. 16:43:28 just one macro to remember would be awesome instead of all that stuff 16:43:29 adamw: How about just python3dep ... which can be used in requires and buildrequires 16:43:30 tibbs: Sure, I can add my gripes to the ticket 16:43:33 it just seems like instead of thinking 'hmm, if they took the trouble to do this it's probably for a reason' you seem to be going with 'bah, i don't understand what this is for so obviously it must be useless!' 16:43:50 I don't want these to come in as a fait accompli that Fedora must use or else. 16:44:01 adamw: I don't think he's claiming that it's useless. 16:44:23 adamw: now you're assuming we're idiots 16:44:24 He's just saying that there's only one core thing that we need to teach people, and a bunch of possibly-useful convenience macros. 16:44:29 adamw: And that's what we are discussing, in the absence of the submitter, we can feed back the salient points into the ticket 16:44:42 it's fine, never mind. 16:44:53 And get feedback 16:45:19 But as a python outsider, it looks overly complex with no justification 16:46:05 The bottom line is that people who aren't intimately familiar with python packaging need to be able to read the document and get what they need from it. It's not supposed to be a complete description of every single available macro. 16:46:31 tibbs: +1 16:46:47 I'm a fan of the KISS principle 16:47:03 Heck, I may have documented too much when I cleaned up the guidelines last time. 16:47:15 we need to make packaging easier, not harder 16:47:49 Will fewer than ~75% of the specfiles need these macros? If so, don't bother showing them in the example spec and the main page. 16:49:35 So.... 16:50:02 ok, so a question to the submitter: Please explain why we need so many new macros instead of one that would just convert the standardized name to the canonical format and add the necessary pythonX.Y() wrapper, i.e. %{pydist 2 foo} which can then be used in both Requires: and BuildRequires: 16:51:23 Rathann: I believe the answer will be that said macros are already in use and thus this is simply documenting what is now existing practice implemented without committee interaction. 16:51:29 But, maybe not. 16:51:38 I'd be in favour of merging py2_* and py3_* macros as well 16:52:03 We can do that; feel free to file a ticket against python-rpm-macros. 16:52:38 I'm trying to keep up and involved with their process now, but I was on vacation and missed most of the development of this stuff. 16:52:40 I need to think about the idea a little before opening a ticket 16:53:22 #action Please explain why we need so many new macros instead of python_dist_name and the necessary pythonX.Y() wrapper, i.e. %{pydist 2 foo} 16:53:23 ok, I veered off track ;) 16:53:34 That good? 16:53:58 pythonX.Ydist() but otherwise goot 16:54:00 *good 16:54:12 also, s/i.e./e.g./ 16:54:18 #undo 16:54:19 Removing item from minutes: ACTION by geppetto at 16:53:22 : Please explain why we need so many new macros instead of python_dist_name and the necessary pythonX.Y() wrapper, i.e. %{pydist 2 foo} 16:54:29 #action Please explain why we need so many new macros instead of python_dist_name and the necessary pythonX.Ydist() wrapper, e.g. %{pydist 2 foo} 16:54:40 👍 16:54:41 ah wait 16:54:42 geppetto: Near enough, I'm happy to expand on my thoughts on ticket 16:54:44 I think I get it 16:54:51 it generates TWO tags 16:55:03 oh, what are they? 16:55:06 Yes, it does. 16:55:09 python2dist(foo) and python2.7dist(foo) 16:55:14 oh 16:55:35 likewise for python3 I guess 16:55:37 So the expansions just before the macros are wrong then? 16:56:06 In that they are missing an output each 16:56:17 #undo 16:56:17 Removing item from minutes: ACTION by geppetto at 16:54:29 : Please explain why we need so many new macros instead of python_dist_name and the necessary pythonX.Ydist() wrapper, e.g. %{pydist 2 foo} 16:56:21 that would be my guess without looking at macro code itself 16:56:47 Ok, so that explains that ... is there anything else specific we want to put in as an action for them? 16:56:51 We definitely need to dig into this (in lieu of having one of the python team on hand) but I just haven't had time. 16:57:13 geppetto: How does it explain? 16:57:40 mbooth: Need requires/buildrequires specific macros ... as it's building 2 of them 16:57:53 ok, I propose we discuss this further on the list and move on 16:57:59 ok 16:58:01 A hypothetical "%{pydist 2 foo}" macro could still generate two tags 16:58:24 mbooth: how? 16:58:24 Result would be "Requires: python2dist(foo), python2.7dist(foo)" 16:58:26 mbooth: but you couldn't use it as Requires: %{pydist 2 foo} >= 1.0 16:58:40 Right, so there's more to it. 16:58:51 BUt... we've been at this an hour. 16:58:52 well, that wouldn't break, but would be inconsistent 16:58:55 And we've lost two folks. 16:59:08 Actually that's true ... how can this work: 16:59:09 %{python3_buildrequires virtualenv} >= 0.6.7 16:59:18 hmm 16:59:29 yeah, we definitely need to look at the macros 16:59:43 tibbs: luckily we still have quorum I think 16:59:44 If that macro expands to two tags ... then we only get the version check on one? 17:00:01 Anyone know how to get the list of chairs still here? 17:00:02 RIght, but we'll lose it eventually if we keep rolling on. 17:00:03 #chair 17:00:03 Current chairs: Rathann geppetto limburgher mbooth orionp racor tibbs 17:00:21 racor left, who else? 17:00:28 but, yeh, we started with 7 17:00:44 I'm still here, barely 17:00:44 geppetto: * limburgher has quit (Quit: Leaving) 17:01:09 hi guys, go/no-go meeting is scheduled in this channel now, how much more do you have (we may be able to move to other channel) 17:01:19 #action Explain how the version requirements work if the macros are generating two requires/Buildrequires each?? 17:01:53 jreznik: I thought we had a reservation for 2 hours... 17:01:54 jreznik: We've finished new tickets ... so we can close soon if you need it 17:02:04 Yeh, I did change that 17:02:28 #fedora-meeting seems free now ;) 17:02:31 I think we can try -2 17:03:01 ok, jreznik ping me after to let me know what told you it was free 17:03:39 #topic #645 Clarify policy on obsoleting non-directly-replaced packages 17:03:45 #topic #645 Clarify policy on obsoleting non-directly-replaced packages 17:03:48 for f24 cycle it seems we were usually in -2. 17:03:51 .fpc 645 17:03:53 geppetto: #645 (Clarify policy on obsoleting non-directly-replaced packages) – fpc - https://fedorahosted.org/fpc/ticket/645 17:04:35 Ok, so adamw gets to argue with us about this ticket now ;) 17:04:46 well, i'm also supposed to be in the go/no-go meeting 17:04:51 Ahh 17:04:53 .nextmeeting 17:04:53 mboddu: (nextmeeting ) -- Return the next meeting scheduled for a particular channel. 17:05:10 .netmeeting #fedora-meeting-1 17:05:15 .nextmeeting #fedora-meeting-1 17:05:19 -> go/no-go meeting - #fedora-meeting-2 17:05:20 geppetto: In #fedora-meeting-1 is Fedora Release Engineering (starting in 3 days) 17:05:23 geppetto: In #fedora-meeting-1 is Fedora-fr (starting in 4 days) 17:05:26 geppetto: In #fedora-meeting-1 is Server SIG (starting in 4 days) 17:05:29 geppetto: - https://apps.fedoraproject.org/calendar/location/fedora-meeting-1%40irc.freenode.net/ 17:05:35 geppetto: both fpc and go/no-go were scheduled the same time in the fedocal 17:05:46 jreznik: Ahh 17:05:55 My only real issue here is that 645 isn't really a packaging thing. 17:05:56 nogo is in -2 17:06:02 I mean, the package is gone. 17:06:24 I don't know what FESCo or release engineering or the installer team or the dnf team thinks is the best thing to do. 17:06:26 I don't mind approving a best practice type thing, if we can agree on what it should be 17:07:14 but I don't want to make something up ... and then other people go lol, I'm not altering fedora-release ... or whatever. 17:07:36 We also say anything else about end of lifed packages, just what packages which are not end of lifed should contain relating to them in the case that they are intended to be replacements. 17:08:02 Or, simpler: why would a packaging guideline say about how to package something which is no longer being packaged? 17:08:12 tibbs: well, to me, retiring a package is inherently a packaging action. 17:08:19 There's a document about handling package end of life. 17:08:23 It's not a packaging guideline. 17:08:24 Well, it could say something about packaging aftermath 17:08:35 yeh, what adamw said 17:08:36 hmm, fair point. who *is* responsible for that page, though? 17:08:42 adamw: Agree, I think there is definitely a general problem that retired packages do not necessarily disappear from systems when they should 17:08:45 https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life 17:09:01 Tells you everything you should do when retiring a package. 17:09:10 yes. i linked to it in the ticket. 17:09:11 it's not under Packaging:, so anyone can edit it 17:09:25 It's not in the Packaging hierarchy, so not really us. It was originally a FESCo action. 17:09:44 *should* it be FPC? i mean, it kinda feels like it should. but if not, fine, i can ask fesco or something. 17:09:54 I have always maintained that this is a FESCo issue and not an FPC issue, and that I personally don't have any idea what the proper thing to do actually is. 17:10:16 Does anyone know the proper action? Is there even one proper action in most cases? 17:10:43 tibbs: We probably could do with input from releng 17:10:48 I think it is packaging related ... but it really needs to be decided by someone who can force people to do things. So either by the people who will do those things, or FESCo 17:11:21 well, i wasn't envisaging anyone *forcing* anything. 17:11:35 _if_ there is something that needs to be done in a package to handle this, then we should certainly have a guideline for it. 17:11:41 But I don't even know if that's the case. 17:11:48 I don't know what the "correct" solution is -- in the past I just added obsoletes to packages that were guaranteed to be present if the obsoleted package was present 17:11:54 i just want that page to say what you do if the package *isn't* replaced by another one, basically. 17:12:10 adamw: Well if the process is to add obsoletes to a package, it needs to be possible for that update to happen quickly when a package goes away 17:12:12 And.. what is that? 17:12:31 I mean, FPC simply does not know what the best practice is. 17:12:35 i don't know. that's why i asked someone to figure it out. :P 17:12:41 the last 25 releases would say ... do nothing ... so it's documented ?;) 17:12:42 * geppetto runs 17:12:58 geppetto: yeah, well, if that's the answer it's the answer, but it'd be nice to at least mention it somehow 17:13:01 I think the best way is what mbooth said 17:13:20 If a eclipse plugin was obsoleted, I could add a Obsoletes: to the base eclipse package, for example <-- this is the only way I could deal with the situation in the past 17:13:22 but I also think it should be decided on a case-by-case basis 17:13:32 But why ask FPC to figure it out? We evaluate proposals for changes to packaging guidelines. There isn't even a proposal for something may or may not involve changes to packaging guidelines. 17:13:47 tibbs: we're supposed to be packaging experts... ;) 17:13:59 Right, but I still maintain that this isn't about packaging. 17:14:23 It's a whole distro thing that deeply involves dnf and the installer but doesn't necessarily involve changes to packages. 17:14:46 I'm not sure we all even have opinions. 17:15:01 We certainly don't have all of the relevant information. 17:15:32 I know that dnf has broken behavior surrounding obsoletes currently but I don't know exactly what it is. 17:15:34 look, if you want to kick it to fesco, you go right ahead. i just picked the most obvious choice. 17:16:08 I guess to me it's not at all obvious why this landed here, that's all. 17:16:57 It kinda depends on the what the "right" solution is as to whether is a packaging issue -- maybe the dnf should remove all retired packages during a system upgrade? In which case, it's a dnf RFE :-) 17:17:06 because it felt like a *packaging* issue to me. so I sent it to the *packaging committee*. 17:17:08 tibbs: i just picked the most obvious choice. 17:17:17 i'm sorry if that was wrong. 17:17:25 it's fine 17:17:53 mbooth: yeah, that's a valid option 17:18:12 But it can certainly be solved through packaging means -- like strategically placed obsoletes 17:18:18 how would dnf know the package is retired? it'd have to have a whole new source of metadata. 17:18:19 I mostly agree, but again ... I don't think we can really get anyone to change processes easily on our own 17:18:26 but sure, there are lots of options. 17:18:37 and not the worst one, though I actually rely on dnf not removing any orphaned packages upon system upgrade 17:18:54 In theory it's just auto remove "yum list distro-extras" on system-upgrade 17:19:11 Or at least mention it to the user 17:19:15 * geppetto shrugs 17:19:16 I've said before that I've no problem if we want a catch-all obsolete crap package to do this. 17:20:05 adamw: The data exists in pkgdb, so maybe dnf could be plumbed into that somehow, I dunno, I'm just an ideas man :-p 17:20:11 And if the people impacted by this stuff decided that was a good solution, sure, we'd put it in a guideline. 17:21:11 I mean, get "obsoleted-packages" into the distribution. FPC can let it bypass process. 17:21:19 Then add packages to that and document it. 17:21:45 But... is that the right thing? It's a distro-wide engineering question. I don't have the expertise to answer that and I'm no longer on fesco. 17:21:59 Hey, Rathann is, though... 17:22:25 I am now ;) 17:22:47 I agree that it would be great to get some other fesco/releng input before we can make any policy decision here 17:22:55 and I agree FESCO should consider this 17:23:41 And then a guideline would read "Note that if a package needs to go away because it will cause depenency issues on upgrades between distribution versions, an Obsoletes: should be added to the "obsoleted-packages" package for the distribution version in which the package is being retired." 17:23:59 Or... something less horrible. Stick that in the current section on obsoletes and provides. 17:24:15 #action Rathann talks to fesco about it 17:24:19 :) 17:24:41 And if that plan is good, then we're ready should fesco or releng or someone tell us that's the way they want the distro to go. 17:25:06 (And it's been... eight years since I last proposed doing that. Everything old is new again.) 17:25:48 #info Obvious possabilities are: "obsoleted-packages" package; metadata from pkgdb; use "yum list distro-extras" logic. 17:26:03 Heh, you said "yum". 17:26:11 And who know in the future, pkgdb/fedpkg could even be automated to add the obseletes tag to that package, then the guideline could go away again :-) 17:26:24 because I'd bet $5 dnf hasn't implemented that command yet 17:26:53 BTW, how do other distros deal with it? 17:27:17 * geppetto tests it and is shocked to discover dnf doesn't implement it, winning his own $5 17:27:25 hehe 17:27:38 That was a sucker bet anyway. 17:27:42 true 17:28:55 Rathann: Will you file a FESCo ticket? 17:28:59 I would guess it needs one. 17:29:09 yes, I'll open one later today 17:29:28 Great, thanks. 17:29:36 ok, we need to beat this horse some more today? 17:30:10 Alright 17:30:14 #topic Open Floor 17:30:22 Well, I did catch up on writeups. 17:30:28 Anyone want to talk about anything? 17:30:37 * geppetto nods ... I saw that tibbs++ 17:30:40 Stuff still in writeup state is waiting on me. 17:30:52 To do other things besides writing stuff up. 17:31:02 tibbs++ 17:31:02 geppetto: Karma for tibbs changed to 3 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:31:06 there we go 17:31:12 I did finish splitting the Naming and Versioning guidelines. 17:31:35 So we have https://fedoraproject.org/wiki/Packaging:Naming and https://fedoraproject.org/wiki/Packaging:Versioning 17:31:43 Ahh, cool 17:31:43 w00t 17:31:43 Which is a bit more manageable. 17:31:46 tibbs++ 17:31:46 Rathann: Karma for tibbs changed to 4 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:32:16 I still wish I could get someone to add the CSS for hiding levels in the table of contents. 17:32:24 But that's not a huge deal. 17:33:05 Also, the gpg stuff is slowly happening. 17:33:25 We have fedora-rpm-macros now so we don't have to worry about breaking redhat-rpm-config. 17:33:54 I managed to break rawhide for about ten minutes with that; luckily I have privs to use koji untag-build. 17:34:04 heh 17:34:15 ok, I need to drop off now 17:34:17 :) 17:34:20 koschei builds will definitely tell you if you screwed up the buildroot. 17:34:28 * geppetto nods 17:34:32 Anyway, ugh, I'm buried at the office and need to split soon too. 17:34:36 Rathann: Take care. 17:34:38 thanks for the meeting and take car 17:39:11 Ok, I'll end the meeting in a minute or so 17:39:35 Thanks. I'm going to run. 17:39:42 ok, see you next week 17:40:49 #endmeeting