From Fedora Project Wiki
(09:04:16) abadger1999: Am I right that the only vetoed item in the Action Items section of GuidelinesTodo is ipv6?
(09:04:29) ***scop has time only about until 1630 UTC today
(09:04:41) abadger1999: So that needs further discussion but everything else is ready to be written up?
(09:05:20) tibbs: I think FESCo was right to declare any attempt to enforce ipv6 via packaging guidelines is dumb.
(09:05:40) tibbs: It's really none of our business.
(09:05:54) lutter: I fully agree
(09:05:55) abadger1999: f13: That's mostly a question for you -- I'm at the FESCo meetings so it's just a question of whether there were any objections from within Core.
(09:06:42) f13: yeah, no problems from COre
(09:07:01) f13: with that, I'm out
(09:07:07) abadger1999: Cool. Thanks.
(09:07:07) scop: abadger1999, do you mean the "writeup" items, or "ratify" too as ready to be written?
(09:07:41) scop: I have a hunch that php and scriptletsnippets need some work
(09:07:56) abadger1999: scop: I'm about to change everything except the ipv6 into writeup.
(09:08:54) abadger1999: When I came up with these, the workflow I saw was: discussion and vote by Packaging; ratification by Core & FESCo; final writeup and entry into the guidelines.
(09:09:04) abadger1999: (these = these categories)
(09:09:16) tibbs: PHP should just need minor changes at this point.
(09:09:44) tibbs: I need to add definitions for the macros so that FC4 can be targeted.
(09:10:04) tibbs: Or make that FC5 if the damn update doesn't get released.
(09:10:28) tibbs: But there's still the bit about whether "requires: php >= version" is necessary.
(09:10:36) tibbs: I admit to zoning out of the argument about that.
(09:11:20) tibbs: I think the discussion ended with something like:
(09:11:52) tibbs: There's no need to require a specific PHP version as long as the release you're targeting satisfied the requirement when it shipped.
(09:11:56) tibbs: Or something like that.
(09:13:01) thimm: Which would make backports to previous FC versions impossible?
(09:13:24) tibbs: Not sure what you mean.
(09:13:26) abadger1999: tibbs: Which is what our current guidelines state....
(09:13:40) tibbs: If a module requires PHP 5, obviously you can't target a release that has only PHP4.
(09:13:41) abadger1999: thimm: Not impossible, just indeterminate.
(09:13:47) thimm: Suppose FC5 has the "right" php version
(09:13:53) thimm: (or FC6)
(09:14:00) thimm: and then you want to branch for FC5 and FC4
(09:14:19) thimm: Suddenly you need to fork the specfile
(09:14:36) tibbs: If FC4's PHP is too old, it's kind of pointless, isn't it?
(09:14:50) abadger1999: scop: If there's something in ScriptletSnippets that needs work, let me know. I'll work on rewriting anything necessary.
(09:14:50) thimm: tibbs: with verison you mean only php4 vs php5?
(09:15:05) scop: cool
(09:15:16) tibbs: thimm: It could be PHP 5.0 vs PHP 5.1.
(09:15:27) scop: by "needs work" I meant primarily that folks read it through etc
(09:15:48) tibbs: Or 4.1.2 vs 4.1.3; I honestly have no idea what kind of incompatibilities they have between versions.
(09:15:52) scop: and editorial changes, such as sonsistency fixes
(09:15:58) scop: s/son/con/
(09:16:17) abadger1999: The more eyes the better :-)
(09:16:46) scop: like if [ $1 -eq 0 ] , not if [ "$1" = 0" ] nor if [ "$1" -eq 0 ] and the like everywhere
(09:16:52) thimm: In that case versioning matters
(09:17:19) thimm: If it were "only" php4 vs php5 one could argue that the platform ingrediends are known and won't change
(09:17:36) thimm: (e.g. there will hardly be a php4->php5 upgrade on FC4)
(09:18:02) thimm: But if it's a depedency on the minor versioning it should be part of the specfile.
(09:18:12) tibbs: Believe me, I don't get Ensc's argument that it's pointless to have versioned dependencies.
(09:18:17) thimm: Just like we do for gfortran depednencies (e.g. gcc-gfortran >= 4.1.1)
(09:18:51) thimm: I'd say if the versioning would go as far back as a couple of FC versions behind it can be dropped, otherwise not.
(09:18:56) tibbs: He edited the draft to what it says now and I can't say why with any certainty.
(09:19:04) thimm: (noone wants to register that gcc >= 2.7 is needed)
(09:19:15) lutter: though it's not really a showstopper
(09:19:21) scop: ensc is being overly pedantic/pessimistic if you ask me
(09:19:29) abadger1999: tibbs: ensc's argument makes sense but is a little convoluted.
(09:19:32) tibbs: So "no need to specify the version if it's satisfied by all targeted releases".
(09:19:39) lutter: I don't see the harm in redundant version requirements
(09:19:55) thimm: "all targeted releases" may be extended
(09:20:10) thimm: E.g. on RHEL, previous FC, FL backports etc.
(09:20:36) thimm: So better to be safe when the versioning would affect near-to-targetted releases
(09:21:01) thimm: => let it to the packager's discretion with a recommendation
(09:21:02) abadger1999: His argument is that versions really only apply per distro as php-4.0.1-5 could be the same as upstream php-4.0.2
(09:21:12) tibbs: I strongly disagree with making maintainers responsible for whatever someone else might want to do with their packages.
(09:21:20) scop: one thing worth noting is that versioning is always accompanied by the package name
(09:21:40) abadger1999: Once you accept that, then versioning when the requirement is satisfied for all the targetted distros is redundant.
(09:21:41) scop: and name based dependencies eg. on shared library ones aren't and shouldn't be recommened
(09:21:48) tibbs: If I'm not targeting RHEL then I don't want to be forced to include junk that makes things work on RHEL.
(09:22:18) lutter: I wouldn't force people, but I would leave it up to them and each individual situation
(09:22:23) thimm: scop: "name based dependencies eg. on shared library ones" are automatically added by rpm
(09:22:25) thimm: ?
(09:22:41) scop: and if I am targeting RHEL then I don't want to be forced to clean up junk that is there to remind me of constraints
(09:22:44) scop: thimm, yes
(09:22:44) tibbs: That's why I said "there's no need to" rather than "you must not".
(09:23:18) thimm: Well, if rpm does that automatically it would not make sense to recommend against it
(09:23:28) thimm: Otherwise we imply that we recommend against rpm's practice
(09:23:29) thimm: do we?
(09:23:30) scop: ?
(09:23:35) scop: I'm confused
(09:23:53) thimm: Well, if you say that we shouldn't recommend what rpm is already doing automatically
(09:24:13) thimm: then we are also recommend that rpm shouldn't inject shared libs dependencies?
(09:24:23) scop: still confused, let me provide an example:
(09:24:37) scop: package A has automatic soname based dependency on libfoo.so.1
(09:24:51) scop: A should not add a dependency on libfoo (the package name)
(09:25:03) thimm: OK, I understand what you meant
(09:25:04) thimm: I agree
(09:26:20) scop: and if one wants more fine grained versioning than sonames, the name based one must be used (eg. libfoo >= x.y.z)
(09:26:51) thimm: We are currently already below 6 people (5), and soon even 4. Does it make sense to continue the meeting?
(09:26:58) thimm: scop: Yes, I agree
(09:27:12) thimm: scop: Usually this shows of bad upstream handling of soname bumping
(09:27:24) thimm: scop: but we need to live with that and add the depednecy
(09:28:37) tibbs: It's a useful discussion in general, but there's no way we could vote on anything. I just wanted to make sure I understood that PHP issue.
(09:30:05) scop: ok, I need to go now, sorry about the short notice but I heard that I won't have more time tonight for these meetings only an hour ago myself :/
(09:30:19) scop: will also miss the fesco meeting, but I posted some stuff to the list
(09:30:31) scop: ttyl
(09:30:49) scop left the room ("Leaving").
(09:30:49) tibbs: Anyone else have anything to work out here?
(09:31:20) tibbs: We know what needs to happen with scriptletsnippets, right?
(09:33:03) thimm: There are some piled up bits that are voting-ready (buildroot, kmdls), but we can't vote, so let's postpone for another time again.
(09:33:57) tibbs: Were we ready to vote on kmdls?
(09:34:06) slack_: What was the status on that?
(09:34:33) tibbs: It looks like things are going to change underneath us again, so it may be prudent to wait until things settle down.
(09:34:42) thimm: I'd say we've discussed it on the list to the bitter end, and all people should have an opinion by now
(09:34:49) thimm: So that's why I call it voter-ready
(09:35:01) tibbs: So where is the complete proposal?
(09:35:06) abadger1999: ScriptletSnippets, yes. Look for problems like scop mentioned. (I've just corrected that issue BTW).
(09:35:15) thimm: There is a blocker, which is uname-are-in-the-name
(09:35:31) thimm: It was brought up that it won't go away, later softened a bit
(09:35:55) thimm: This needs to be addressed first and lays out the fate of the rest
(09:36:01) tibbs: RIght, where is the proposal? I think we need to see the proposal written down, with the pros and cons listed.
(09:36:35) thimm: When spot wrote that uname-are-in-name will never get by him I stopped working on the proposal
(09:36:56) thimm: I'mnot going to spend a couple of hours/days into something known top be rejected
(09:36:57) tibbs: Then what is the point of ever voting?
(09:37:01) thimm: I wrote about it on the list
(09:37:12) thimm: Voting about uname-are-in-name
(09:37:25) thimm: If it is rejected, then the whole kmdl stiff goes down /dev/null
(09:37:38) thimm: If it's accepted I'll continue the kmdl crusade
(09:38:03) slack_: are you advocating adding that to the existing proposal or a completely different one?
(09:39:01) tibbs: I personally won't vote for any change in the status quo unless I understand fully what it gets us.
(09:39:02) thimm: The current proposal (which isn't a proposal anymore, it is guidelines) does not have uname-are-in-name
(09:39:15) thimm: and therefore exhibits flaws as outlined on the fedora-packaging-list
(09:39:29) tibbs: I can't figure that out from the list discussion, which is why I want to read a summary.
(09:39:43) abadger1999: thimm: Is the current behaviour all wrong or only potentially wrong? (ie: It works 80+% of the time but is a bit hacky)
(09:39:47) slack_: tibbs: and this point was well discussed when we were working on the current guidelines
(09:39:53) thimm: tibbs: It was demonstrated that the current scheme is broken, and also argumented to a large extend that only a scheme with uname-are-in-name can save the day
(09:40:13) tibbs: But if you're not willing to write a summary somewhere, then I guess you can count on me not voting for you.
(09:40:21) tibbs: Sorry, your choice.
(09:40:25) thimm: abadget1999: I t break whenever you have two kernel installed
(09:40:49) thimm: tibbs: I'm not after a card blanche
(09:41:11) thimm: tibbs: It's about recognising that there is a problem that needs to be fixed
(09:41:32) thimm: If the problem is not considered a problem, then there is nothing to fix, so why waste time
(09:41:52) thimm: I just argue that there is severe breakage in any scheme not using uname-are-in-name
(09:42:04) thimm: It was demonstrated on the list with actual examples
(09:42:15) thimm: And there are even users that quote this bugs
(09:42:44) thimm: The current scheme *requires* to violate typical rpm ordering rules
(09:43:19) thimm: The "neither rpm -U, nor rpm -i" can do the proper operation argument of the list
(09:44:13) thimm: Anyway, as said, I think most have their opinion on the matter made up
(09:44:35) thimm: So it's only fair to vote about it even if it's rather certain to be turned down
(09:44:42) abadger1999: Right. How broken though? rpm -Uvh will erase the previous versions so that's not going to work. rpm -ivh will fail because it is asked to overwrite the previous kmod-version's files so that's broken too? Only rpm -ivh --replacefiles will "work"?
(09:44:47) thimm: I just don't want it to be stalled and unreviewed
(09:45:18) thimm: abadget1999: No because you would end up with several packages owning the same files
(09:45:25) tibbs: I for one haven't formed an opinion yet.
(09:45:53) tibbs: Still, I'd want to see how any changes to the standard mesh with the kabi stuff.
(09:46:13) tibbs: Which is tough right now since we don't know exactly where that's going yet.
(09:46:29) slack_: So...there haven't been status changes from what was last on the list. Why don't we table this until we have the summary document for suggested changes to the current quidelines.
(09:46:29) thimm: The kabi stuff is not going to really help
(09:46:45) thimm: kabi was also dicussed on the list
(09:47:00) abadger1999: thimm: I'm on the fence about how big a problem multi-ownership is in this case. Having to use "--replacefiles" as the only way to get it installed is a much bigger deal to me.
(09:47:30) thimm: At any rate it is a hack or worse
(09:47:40) thimm: While the proposed scheme works great in rpm's world
(09:47:56) thimm: The only argument against it is the uname-are-in-name uglyness
(09:48:01) thimm: And that drives me crazy
(09:48:23) thimm: We're not on a beauty contest, we're trying to get thing working properly.
(09:48:27) abadger1999: :-) Right.
(09:48:46) abadger1999: How does modutils determine what module to load when there are two potential candidates?
(09:49:23) thimm: <lie> There are never two potential candidates in any of both schemes
(09:49:25) abadger1999: test1.0/foomod.ko and test2.0/foomod.ko for example
(09:49:42) thimm: What is test1.0 and test2.0?
(09:49:46) abadger1999: This is the start of a new scheme.
(09:49:48) thimm: The module's version?
(09:49:59) littlecharly [n=charles] entered the room.
(09:50:02) abadger1999: Perhaps.
(09:50:08) abadger1999: I'm half thinking out loud.
(09:50:10) thimm: modutils has some directories that are prefereed (/updates/, extras/)
(09:50:25) thimm: the rest is simply read by stat
(09:50:41) thimm: So for the rest it's what comes first in a rather random order
(09:50:59) thimm: If an external kernel module need to override a kernel's
(09:51:14) thimm: modutils make that possibly by placing it in /updates/ or /extras/
(09:51:21) thimm: possibly->possible
(09:51:33) abadger1999: Ugh. Randomness is no good for our purposes.
(09:52:00) thimm: the kabi people want to have modutils look at old places, too an dcheck for "weak" compliance
(09:52:30) thimm: E.g. try to reuse a kernel module from an old kernekl if the current one doesn't provide one
(09:52:43) thimm: That's all the kerneldriver project will be doing
(09:54:22) abadger1999: If they do it right, they could have something like: /lib/modules/fs/ntfs/{1.0,2.0,3.0}/[KABI] /ntfs.ko as the filesystem layout then
(09:54:25) tibbs: It's a truly great idea if it works.
(09:55:07) thimm: don't mistake that for a stable kernel api!
(09:55:45) thimm: Check out /usr/share/doc/kernel-doc-2.6.17/Documentation/stable_api_nonsense.txt
(09:55:57) tibbs: It seems to me to only be a recognition that the API doesn't necessarily change with every update.
(09:56:09) tibbs: And that the entire API doesn't necessarily change at once.
(09:56:24) thimm: It changes on each kernel release at the very least
(09:56:45) thimm: tracking FC6 with kernel modules I see almost weekly a breakage in some kmdl
(09:56:51) thimm: becasue of api changes
(09:56:57) tibbs: But not necessarily with every tiny bug fix.
(09:57:07) thimm: Not by security fixes, no
(09:57:16) thimm: So it's interesting for RHEL, but not for FC.
(09:57:29) tibbs: Definitely interesting for FC.
(09:57:29) thimm: Even the xen pathces cahnge the api
(09:57:37) thimm: at places where you wouldn't suspect it
(09:57:44) thimm: for example in the v4l2/dvb subsystem
(09:57:45) tibbs: If it saves me even 10% of module upgrade deadlock I'm happy.
(09:58:03) thimm: So consider it a complement to any kmod/kmdl scheme
(09:58:16) thimm: But it can't replace them or even alter them in their scope and functionality
(10:00:24) thimm: See you next week, and happy FC6t2 by then! :)
(10:02:27) abadger1999: thimm: Hey Axel -- Did the FHS make any progress with libexecdir?
(10:19:05) littlecharly left the room (quit: Read error: 110 (Connection timed out)).
(11:25:30) thimm: abadget1999: On FHS: There was feedback by the authors and I clarified some bits and am waiting anew for feedback.
(11:25:37) thimm: It's a very slow process