Meeting:Packaging IRC log 20060713

(08:56:16) spot has changed the topic to: Channel for Fedora packaging related discussion | Next Meeting: Thursday, July 13th, 2006 16:00 UTC
(08:58:01) ChanServ [ChanServ]  entered the room.
(08:58:01) mode (+o ChanServ ) by irc.freenode.net
(08:59:02) scop [n=scop]  entered the room.
(09:00:07) mode (+v abadger1999 ) by spot
(09:00:10) mode (+v f13 ) by spot
(09:00:17) mode (+v lutter ) by spot
(09:00:28) mode (+v rdieter ) by spot
(09:00:31) tibbs: blah
(09:00:41) mode (+v scop ) by spot
(09:00:48) spot: i'm not moderating, just counting
(09:01:02) mode (+v tibbs ) by spot
(09:01:10) mode (-o spot ) by spot
(09:01:30) mode (+v spot ) by ChanServ
(09:02:02) spot: two missing people, ralf and jose.
(09:02:14) racor [n=rc040203]  entered the room.
(09:02:16) scop: and axel
(09:02:24) spot: ahh, yes.
(09:02:47) f13: ok, I"m here.
(09:03:06) f13: however, I need to run downstairs and grab a plate / mayo real quick.  I'll be back in like 4 minutes
(09:05:06) lutter: morning guys
(09:05:16) scop: evening :)
(09:06:07) tibbs: So should we wait for thimm and jpo?
(09:06:24) f13: back.
(09:06:33) scop: voice to racor?
(09:06:47) racor: hmm?
(09:06:51) mode (+v racor ) by ChanServ
(09:07:22) spot: lets give the remaining folks a minute or two
(09:07:30) scop: nm, I'm still an IRC n00b
(09:07:47) racor: so am I ;)
(09:08:15) spot: i think theres one item on the agenda that is so obvious it will pass without question
(09:08:25) spot: Honoring of $RPM_OPT_FLAGS needs to be explicitly mentioned in packaging/review guidelines
(09:08:34) scop: right
(09:08:40) f13: +1
(09:08:45) spot: +1
(09:08:45) f13: mention its for security too
(09:08:49) tibbs: +1
(09:09:34) spot: ...then again, maybe i'm wrong.
(09:09:40) scop: +1
(09:09:43) lutter: +1
(09:10:01) racor: +1
(09:10:07) spot: alright, thats 6. :)
(09:10:10) tibbs: Don't forget to allow %{optflags} and make it clear that noarch packages don't need to try to use it.
(09:10:20) spot: yup.
(09:10:33) spot: ok, thats the only EasyFix item.
(09:10:38) spot: the rest should be fun.
(09:10:47) f13: fvmo fun.
(09:10:55) spot: lets start with a follow-up from last meeting
(09:11:06) spot: we decided to adopt PackagingDrafts/Changelog
(09:11:16) spot: but it was unclear whether this is a MUST or a SHOULD
(09:11:30) spot: i think it should be a MUST
(09:11:33) f13: Must have a changelog, Must follow one of the templates.
(09:11:45) abadger1999: I agree.
(09:12:01) spot: +1 for MUST
(09:12:25) scop: many people tend to obfuscate their email address in changelog entries, does anyone see a problem with that?
(09:12:28) tibbs: Must have changelog, those corresponding to package version changes must include version in one of the three templates.
(09:12:49) lutter: no, as long as a human can figure it out from owners.list
(09:12:50) ***spot doesn't see any big problem with obfuscation as long as there is _something_ there. :)
(09:12:54) tibbs: No problem for me with obsfucation as long as it's reasonably clear how to get a real address out.
(09:13:25) spot: is anyone opposed to making this a MUST?
(09:13:35) rdieter: hi guys, sorry I'm late.
(09:13:43) abadger1999: +1 MUST
(09:13:45) scop: +1 (not opposed)
(09:13:53) tibbs: +1 must
(09:13:54) lutter: no, I think that's fine (ideally we could stick to one format, but I don't feel like causing another 100+ email thread)
(09:13:57) racor: spot: to make what a must?
(09:14:09) lutter: racor: the changelog format
(09:14:12) spot: racor: the PackagingDrafts/Changelog format
(09:14:18) rdieter: +1
(09:14:20) racor: 0
(09:14:37) spot: i count 6 with lutter.
(09:14:39) lutter: +1
(09:15:01) spot: alright, next item on the list: ipv6 in Fedora
(09:15:14) spot: It is proposed that all packages in Fedora SHOULD have ipv6 support
(09:15:28) lutter: I don't think it's a packaging question
(09:15:29) spot: If they do not, the maintainer MUST open a bug and work with upstream to implement ipv6 functionality
(09:15:44) tibbs: I am against requiring that reviewers check this.
(09:16:18) spot: the point was made that we have a similar rule in place for architecture support
(09:16:37) tibbs: Arch support gets checked by the buildsys.
(09:16:38) scop: well, reviewers can't check all archs either
(09:16:44) abadger1999: I think a bug being opened is fine.  Working with upstream is unreasonable (We don't require the packager to fix arch support either.)
(09:16:45) scop: tibbs--
(09:17:03) scop: "builds, it works" is something we really need to discourage
(09:17:18) rdieter: I agree with abagder1999, I think it's sufficient to document the deficiency, perhaps report upstream...
(09:17:28) abadger1999: Err... mandatory working with upstream is unreasonable :-)
(09:17:30) rdieter: "work with" seems a big vague
(09:17:36) tibbs: scop: then drop the minority platforms.
(09:17:39) scop: ...and in this case, just admit that it's the end users who will test
(09:17:45) scop: no
(09:17:45) spot: ok, change the wording to "notify upstream"
(09:17:59) f13: the problem in Extras is there is no extras technical overview to deem a package worth to be in Extras
(09:18:01) spot: MUST open a bug and notify upstream
(09:18:18) rdieter: that I think is reasonable, +1
(09:18:21) f13: in Core, we have reviewers that review a package, and then a technical overview that says "yes this package is allowed in extras"
(09:18:39) f13: in Extras, the reviewer is also playing this role.
(09:18:55) lutter: I don't think we should mandate that people check functionality of packages
(09:19:08) spot: Can we vote on this proposal?
(09:19:14) abadger1999: Hmmm I don't see the arch requirement on Pakcaging/Guidelines.
(09:19:14) f13: lutter: if we don't, who will?
(09:19:30) spot: It is proposed that all packages in Fedora SHOULD have ipv6 support, if they do not, the maintainer MUST open a bug and notify upstream
(09:19:36) racor: lutter: +1, it's impossible for FE reviewers
(09:19:37) spot: abadger1999: its in ReviewGuidelines
(09:19:40) f13: spot: +1
(09:19:47) scop: +1
(09:19:49) tibbs: spor: -1 to any must.
(09:19:49) lutter: -1
(09:20:00) abadger1999: 0
(09:20:07) rdieter: +1
(09:20:10) racor: 0, non realistic
(09:20:35) spot: OK, it doesn't pass.
(09:20:49) tibbs: s/must/should/ and I think it's reasonable.
(09:20:51) scop: by the way, how do -1's affect the voting resulits?
(09:20:51) lutter: f13: I don't want to make reviews take even longer than they do today, especially for something that isn't really something that leads to problems packaging wise
(09:21:05) spot: OK, here is how i interpret votes
(09:21:07) spot: +1 yes
(09:21:09) f13: the revierw doesn't have to check for the functionality
(09:21:10) lutter: scop: I'd say the same as 0
(09:21:11) scop: same as 0, or cancel one +1
(09:21:16) spot: 0 no opinion, abstain
(09:21:18) spot: -1 no
(09:21:19) f13: the reviewer can ASK the reviewee if the software has the fucntionality
(09:21:41) spot: do we want to vote on a SHOULD SHOULD policy?
(09:21:46) f13: Question: Does this software support ipv6 (if its' netowrk enabled)
(09:22:00) f13: reviee answers: no, here is bug.  or Yes.
(09:22:04) f13: reviewer moves on.
(09:22:24) scop: so effectively, 0 vs -1 is "just for the record", same effect on result
(09:22:33) tibbs: f13: I have no problem with that.
(09:22:41) racor: f13: 95% of all reviewers and packagers probably don't even understand this question
(09:22:41) tibbs: spot: I second a vote for should-should.
(09:22:49) spot: scop: yes
(09:22:54) f13: w/out a technical overviewer of Extras as a whole to pay attention to these things, we need the reviewers to handle it.
(09:23:16) f13: I give +1 to either Should/Must or Should/Should
(09:23:29) rdieter: I'm +1 either way.
(09:23:32) spot: it is worth noting that a SHOULD/SHOULD policy will likely be ignored by the majority of packagers, and cannot stop a review.
(09:23:37) racor: +1 for should/should
(09:23:55) tibbs: +1 for should/should.
(09:23:57) scop: +1, much better than nothing
(09:24:06) spot: +1
(09:24:11) spot: ok, it passes
(09:24:15) tibbs: spot: People who really care about this can look over packages if they want.
(09:24:17) abadger1999: Are we opening a bug upstream or blocking a Fedora Bug?
(09:24:18) lutter: I'm still at a 0 .. the whole issue just seems orthogonal to what the packaging guidelines try to achieve
(09:24:19) f13: spot: it still gets the packager thinking about it, especially if prompted by the reviewer
(09:24:34) ***scop is afk for ~3 minutes
(09:24:49) f13: lutter: unfortunately the packaging guidelines also cover some basics of software quality
(09:24:59) spot: abadger1999: I think it should be a Fedora bug blocker, so that people who care about ipv6 can have some semblance of tracking
(09:25:08) abadger1999: I agree with that.
(09:25:15) f13: spot: sounds right to me.
(09:25:20) rdieter: blocker++
(09:25:33) lutter: f13: what other issues are treated in that way ?
(09:25:39) ***f13 wonders if an ipv6 SIG will show up.
(09:25:53) spot: ok. i'm going to move on
(09:25:55) tibbs: +1 for blocker, +1 for upstream report as well.
(09:26:13) spot: Next topic: bumping release number AFTER the dist tag
(09:26:21) spot: right now, this isn't really permitted, but people are doing it
(09:26:34) spot: the pro: it lets you bump within a dist without bumping ALL dists
(09:26:51) spot: the con: if the SRPM is built where dist is undefined, it can get confusing as to ordering
(09:26:52) ***scop is back
(09:26:59) tibbs: This also conflicts with the proposed "fc5.91" scheme.
(09:27:09) f13: lutter: hrm, I thought there was another exmaple, but I can't find it.
(09:27:20) lutter: f13: ;)
(09:27:23) f13: tibbs: I'm OK with that. (:
(09:27:53) f13: lutter: regardless, w/out a technical overview, reviewers do have some responsability in what is being packaged for Extras.
(09:27:56) rdieter: tibbs not really, unless the postfix # is > 90.
(09:27:59) f13: lutter: call it an exteded ForbiddenItems
(09:28:12) scop: I don't see any other way to do bugfixes to older distros only
(09:28:19) f13: I don't either.
(09:28:30) lutter: tibbs: what if the guidelines state that you need to keep your branch number below 90 (or 50 or whatever) .. so if you really, really have to rebuild for an older release more than 50 times, you need to use fc5.50.1
(09:28:31) rdieter: IMO, it's ok.
(09:28:48) f13: I'm +1 for allowing %{?dist}.foo
(09:29:10) racor: lutter: still ambiguous and confusing syntax
(09:29:13) f13: but noting that it can cause issues if rebuilt w/ undefined %{dist}
(09:29:17) tibbs: It's not just a numerical conflict; it's conceptual.
(09:29:50) f13: tibbs: then its a failing of the %{?dist} tag logic
(09:30:07) f13: forcing folks to bump other releases just to keep ordering right is not sane.
(09:30:18) lutter: yeah, we have two different ordering criteria, but only one way to express them; it doesn't seem there's a better way to accomodate both needs
(09:30:20) spot: i'm hesitant to discuss the development dist scheme proposal without axel
(09:30:20) tibbs: I think the security team and legacy will want something like this so that they can fix bugs without having to coordinate version bumps for N later releases.
(09:30:38) racor: f13: nope, the fault is not having strict convention/syntax on %release
(09:30:53) tibbs: spot: Good point, and if we approve this then we effectively nix his proposal.
(09:31:04) f13: racor: proposal?
(09:31:27) spot: hmm. how about this
(09:31:29) racor: <int>%{?dist}<int>
(09:31:42) f13: racor: 3.fc63
(09:31:43) f13: ?
(09:31:51) spot: if you want to bump after the dist, do so like .00n
(09:32:00) racor: with dist = .fcN, no .fc5.90
(09:32:00) spot: where n is the integer being bumped
(09:32:12) spot: the padding protects it from potential devel naming
(09:32:14) f13: racor: 3.fc63 or 3.fc6.3
(09:32:18) scop: $ fedora-rpmvercmp 0 0 3.fc63 0 0 3.fc7
(09:32:18) scop: 0:0-3.fc63 is newer
(09:32:35) rdieter: so, something like <int>%{?dist}<bar>, where bar will probably be <int> too?
(09:32:35) spot: so, 0 0 3.fc6.001
(09:33:05) rdieter: i like it, it's definitely safer
(09:33:07) racor: Sorry typo: 3.fc6.3
(09:33:12) f13: spot: that protects when build ast 3.001 compared to 3 in devel ?
(09:33:17) f13: or 3.fc6 ?
(09:33:28) ***scop is confused
(09:33:37) f13: racor: I'm in favor of allowing an int after %{?dist}
(09:33:38) rdieter: I protects when/if we ever use fc5.90 for deve.
(09:33:50) rdieter: for devel %{?dist} that is
(09:34:02) spot: ok, here's the issue, lemme try to make this clear
(09:34:18) spot: right now we do NOT permit people to add anything after the %{dist} tag in Release
(09:34:48) spot: but this keeps people from being able to make a single dist change to an older dist without rebuilding all later dists
(09:35:11) spot: because 3.1.fc3 is greater than 3.fc6
(09:35:26) spot: the workaround is to let people add something after the dist tag
(09:35:43) spot: i propose that we standardize on a .00n
(09:35:52) spot: so people can add .001 after the dist tag
(09:35:59) spot: then increment that within the dist if necessary
(09:36:02) lutter: but for rpm that's the same as adding .1
(09:36:10) rdieter: no it's not. (:
(09:36:15) abadger1999: It would have to have another period in it.
(09:36:32) spot: we could put another period in it and lose a 0
(09:36:33) scop: $ fedora-rpmvercmp 0 0 3.fc6.001 0 0 3.fc6.1
(09:36:33) scop: These are Equal
(09:36:40) spot: so 3%{dist}.0.1
(09:37:03) rdieter: interesting.
(09:37:03) scop: what's the problem with just .1?
(09:37:22) spot: scop: there is a proposal on the table to use dist tags for devel  branches
(09:37:24) rdieter: I say keep things simpler, for now, stick with .<int>
(09:37:27) lutter: that we also want the first field after %dist for noting rahide/test
(09:37:29) spot: e.g. .fc5.90
(09:37:48) scop: yes, and if someone overflows *90* with the .1 scheme, we have bigger things to worry about
(09:37:48) f13: I'm highly against making the devel dist tag vastly different from the released dist tag.
(09:37:50) abadger1999: 1) Are we making a mountain out of a molehill of the potential conflict?
(09:37:52) f13: this is just confusing.
(09:38:02) racor: lutter: -1
(09:38:06) spot: scop: but its feasible that someone COULD overflow 90
(09:38:09) lutter: abadger1999: I think so
(09:38:20) scop: spot, I don't buy that
(09:38:23) lutter: spot: then they have to use .89.1
(09:38:28) racor: lutter: Why? This doesn't buy you anything.
(09:38:39) spot: ok, do we want to say that the additional digit cannot be >= 90?
(09:38:50) rdieter: imo, these are separate issues, when/if we (re)visit the fc5.90 issue, we can revisit the stuff after %{?dist} one
(09:38:51) lutter: racor: not sure what exactly you are disagreeing with
(09:39:01) f13: spot: can we make that rule *if* axel's proposal goes through?
(09:39:04) scop: rdieter++
(09:39:09) spot: f13: sure.
(09:39:12) f13: spot: lets not make rules to help w/ undefined rules.
(09:39:20) spot: we can do whatever we want, really. :)
(09:39:30) f13: Please vote for allowing <int>%{?dist}<int>
(09:39:33) racor: lutter: What does this tag help you?
(09:39:34) f13: +1
(09:39:39) rdieter: +1
(09:39:41) scop: and we should make it at least a SHOULD that the trailing .X goes away when there's the first chance to do that
(09:39:42) f13: Please vote for allowing <int>%{?dist}.<int>
(09:39:42) abadger1999: +1
(09:39:42) tibbs: +1
(09:39:46) scop: +1
(09:39:48) spot: f13: <int>%{?dist}.<int>
(09:39:48) racor: +1
(09:39:51) spot: that . is pivotal
(09:39:51) lutter: rdieter: to be on the safe side, I'd rather tell people that the number has to be < 90 for now, and take that restriction away if we don't use the devel scheme .. always easier to take a restriction away than impose one
(09:40:21) lutter: +1
(09:40:23) rdieter: lutter: don't care...
(09:40:28) f13: lutter: I highly doubt we're going to get anybody having a .90 after dist by the time we vote on Axel's proposal.
(09:40:56) spot: f13: you onboard with the . in there?
(09:40:57) lutter: f13: I highly doubt we ever will, but it's better to be very clear
(09:41:07) f13: spot: didn't you see me repost the Vote ?  before you even mentioned it.
(09:41:25) spot: f13> Please vote for allowing <int>%{?dist}<int>
(09:41:27) f13: lutter: I'd rather not clutter the rule with extra rules for a yet unvoted on proposal.
(09:41:37) f13: <+f13> Please vote for allowing <int>%{?dist}<int>
(09:41:37) f13: <+racor> lutter: What does this tag help you?
(09:41:37) f13: <+f13> +1
(09:41:37) f13: <+rdieter> +1
(09:41:37) f13: <+f13> Please vote for allowing <int>%{?dist}.<int>
(09:41:54) spot: oh. duh.
(09:42:00) spot: senility again, sorry. :)
(09:42:00) rdieter: <+f13>+1
(09:42:02) f13: we got 6 votes.
(09:42:16) spot: ok, next item (not on the agenda, just remembered it)
(09:42:30) spot: Do we want to permit the hardcoding of dist tags?
(09:42:50) spot: e.g.  Release: 3.fc6 as opposed to 3%{?dist} ?
(09:42:53) f13: spot: Yes.
(09:43:01) tibbs: Only if there's zero chance that it would conflict with an automatic branch.
(09:43:07) f13: IMHO the packager should be allowed, he just has to follow the naming guidelines.
(09:43:20) spot: tibbs: i guarantee it will conflict with an automatic branch.
(09:43:22) f13: s/he/he\/she/
(09:43:24) racor: -1, this is a major pain when rebuilding new packages on older packages (e.g. rawhide package for .fcN)
(09:43:33) spot: I vote -1 on this as well
(09:43:50) lutter: yeah, I don't see why hardcoding is a big win, -1
(09:43:53) tibbs: -1 from me due to the potential for conflicts.
(09:43:58) rdieter: I'd say (if the guidelines don't already say it), that one SHOULD use %dist, but not MUST (ie, hard-coding *is* ok)
(09:44:04) scop: 0
(09:44:04) f13: Right.
(09:44:34) f13: I'm ok w/ forcing %{?dist} if you want to make a tag, but we should _not_ force folks to use %{?dist} on every pacakge.
(09:44:38) spot: the argument for hardcoding is that the packager intends it to be only for that branch, always and forever
(09:44:42) abadger1999: I haven't seen anything that says what benefit it would have... 0
(09:44:49) tibbs: Now, what if someone uses %{?dist} but defines it to something earlier in the spec?
(09:45:00) f13: tibbs: don't approve that package.
(09:45:00) rdieter: tibbs: bad, no-no.
(09:45:02) spot: defining dist is also not permitted currently.
(09:45:05) lutter: that should be very forbidden
(09:45:23) tibbs: You know someone will try....
(09:45:34) f13: rule proposal:
(09:46:04) spot: "#
(09:46:04) spot: You cannot override the variables for %{dist} (or any of the related variables).
(09:46:04) spot: #
(09:46:04) spot: You cannot hardcode a value for %{dist} (or any of the related variables) in your spec."
(09:46:09) f13: *IF* you wish to have a tag that identifies the distribution, you *MUST* use %{?dist} for this.  *HOWEVER* you are *NOT* forced to have the identification tag.
(09:46:11) spot: thats in DistTag right now
(09:46:26) spot: f13: this is how it works now
(09:46:32) spot: disttag is not mandatory
(09:46:55) spot: but if you want to identify dist, its %{dist} or nothing
(09:47:08) tibbs: Hmm, we should move DistTag to live under Packaging.
(09:47:22) spot: tibbs: yeah, i do not possess the wiki fu to move the page
(09:47:24) lutter: I would like to leave the disttag rule that way
(09:47:45) scop: by the way, we should get another name for "disttag"
(09:47:59) tibbs: spot: Cut and paste is the only way I know.
(09:48:05) scop: $ grep Disttag /usr/share/doc/rpm-*/CHANGES
(09:48:05) scop:         - add Disttag: syntax to spec file parser and header content.
(09:48:19) spot: scop: let me put this as politely as i can.
(09:48:30) spot: jbj is actively trying to fuck half the world over with rpm.
(09:48:45) lutter: what it really tells you (and why I find it useful) is that it tells you what buildroot a pkg was built against
(09:48:47) spot: i don't plan on doing anything to avoid namespace conflict with him unless it is absolutely necessary
(09:49:19) scop: well, that entry is from rpm already shipping with FC
(09:49:31) spot: yes, but it doesn't really matter what we call it on the wiki
(09:49:40) spot: as long as our macro defines aren't overridden
(09:49:55) f13: scop: he's shorthanding Distribution: header.
(09:50:08) scop: f13, I think those are separate
(09:50:24) f13: ok, so vote to keep the dist tag rules exactly as they are?
(09:50:31) spot: we don't need to vote for that. :)
(09:50:32) f13: (seems silly)
(09:50:45) tibbs: That was easy.
(09:50:47) spot: ok, we've got 10 minutes left
(09:50:51) f13: well, we need closure on the agenda item.
(09:50:54) spot: are there any items people want to discuss
(09:51:01) abadger1999: Jpackage naming
(09:51:01) f13: *cough* java
(09:51:10) rdieter: eek.
(09:51:16) abadger1999: scop: Are you active with jpackage?
(09:51:18) f13: however, I think we need to have more list discussion
(09:51:28) spot: i think we all need to think about that more.
(09:51:31) scop: abadger1999, "in hibernation" would be more accurate
(09:51:33) rdieter: f13: I agree.
(09:51:37) f13: because nothing was really agreed on the list and offered up for approval.
(09:51:39) spot: if we vote now, i suspect it will fail.
(09:51:51) tibbs: I suspect it will fail anyway.
(09:51:53) spot: but i want to make sure everyone has a well informed vote
(09:52:01) spot: so that no one can scream about a vote full of 0s
(09:52:02) lutter: yeah, I would like to get a clearer statement from fnasser etc. about this
(09:52:06) f13: and ya'all can flog me later for introducing 1075 non-int release numbers.
(09:52:34) f13: spot: noarch package topic.
(09:52:36) abadger1999: spot, f13: Are there certain people within RedHat we should ask about this (like gbenson)?
(09:52:48) spot: abadger1999: gbenson seems like an obvious starting point
(09:52:50) f13: abadger1999: he's been cc'd on the mails to packaging list no?
(09:53:07) lutter: abadger1999: I'll drop a reminder on the internal java list
(09:53:11) spot: f13: can you sum up the noarch thing quickly?
(09:53:11) abadger1999: All the mails have been to maintainers.  Not sure if he's CC'd.
(09:53:38) scop: suggestion: rename "packaging guidelines" to "packaging policy"
(09:53:45) f13: spot: if your package is made from non-arch files (python) but only works for certain arches, you must make your package of that arch, it cannot be noarch.
(09:53:46) scop: MUST sounds odd with "guidelines"
(09:54:07) spot: f13: we lose the ability to save space with that.
(09:54:12) lutter: very firm guidelines, these are
(09:54:13) f13: spot: space saving is minimal.
(09:54:22) spot: f13: should we just ExcludeArch: broken arches?>
(09:54:31) f13: spot: but right now we're massivly abusing the ExcludeArch and ExclusiveArch tags
(09:54:41) f13: spot: that header information isn't in the binary package result.
(09:54:46) spot: hmm.
(09:54:46) f13: spot: it is only in the srpm.
(09:54:58) spot: that sounds like something that should/could be fixed in rpm
(09:54:58) abadger1999: f13: Looks like gbenson hasn't been CC'd to the jpackage naming discussion.
(09:55:10) f13: spot: yes, but for now.
(09:55:20) spot: f13: can you ask pnasrat how feasible it would be to implement that?
(09:55:27) f13: spot: -ENOTANYTIMESOON
(09:55:39) tibbs: I would prefer to leave noarch alone.  If I package a shell script that parses the i386 /proc/cpuinfo output, it should still be noarch.
(09:55:40) f13: spot: I would hazard it would be sometime around FC7 for that
(09:55:52) lutter: f13: unless it will cause major infrastructure blowup, I'd rather we wouldn't allow .noarch packages in those situations
(09:55:55) rdieter: should we consider adding some sort of commented tag to help the push scripts just "do the right thing"
(09:55:56) f13: tibbs: how do you prevent it from being installed on s390 ?
(09:55:59) spot: f13: i would prefer to have people filing bugs against code that doesn't work on a specific arch
(09:56:06) spot: rather than abusing noarch code
(09:56:12) f13: spot: system-config-boot ?
(09:56:15) f13: covers grub.
(09:56:31) f13: shell scripts to do acpi stuff?
(09:56:33) f13: thats x86
(09:56:38) tibbs: You don't.  The package contains no binaries, so it's noarch.  We don't have "allarch" packages.
(09:56:42) f13: shell scripts to handle elilo?
(09:56:44) f13: thats ia64
(09:57:02) spot: again, this is an rpm limitation
(09:57:04) f13: tibbs: no, but with arch specific packages we have an easy way to exclude them.
(09:57:13) f13: spot: yes, it is, however it is unlikely to be fixed any time soon
(09:57:15) lutter: yeah, calling it 'anyarch-i-don't-care' would be more fitting than noarch
(09:57:25) racor: spot: Actually a build/release system limitation
(09:57:50) rdieter: I think I agree with the proposal, it seems the best/simplest solution to the problem at hand.
(09:58:01) tibbs: try this example:
(09:58:09) tibbs: I have exported /usr/share.
(09:58:12) f13: if your package is arch specific, regardless of what it is made up of, it must be arch specific and not noarch.
(09:58:19) spot: we've got two minutes here folks... :)
(09:58:25) tibbs: I install a noarch package that puts things into /usr/share.
(09:58:33) tibbs: The arch of the file server isn't important.
(09:59:00) spot: Lets vote on: If your package is arch specific, regardless of what it is made up of, it must be arch specific and not noarch.
(09:59:16) abadger1999: 0
(09:59:19) f13: +1
(09:59:21) rdieter: +1
(09:59:22) lutter: +1
(09:59:24) racor: 0, need to think about it
(09:59:35) scop: stating the obvious...
(09:59:41) tibbs: -1
(09:59:48) scop: +1
(10:00:16) spot: it doesn't pass. lets put it back on the agenda for next week
(10:00:17) scop: time's up
(10:00:22) f13: ok.
(10:00:36) spot: and now, off to report to FESCO. thanks guys. :)
(10:01:35) f13: cheers
(10:01:49) scop: thanks, I'm off to the FESCO meeting too, seeya
(10:01:58) scop left the room ("Leaving").
(10:02:12) f13: tibbs: what about sharing /usr/bin?  You've got to deal with that too
(10:02:29) f13: tibbs: a file server's /usr/bin may have arch specific stuff in it, x86_64 vs i386
(10:03:36) f13: tibbs: your suggestion is a bit of a hyperbol, because right now we are abusing ExcludeARch and ExclusiveArch srpm headers to prevent these noarch arch specific packages from being shipped on said arches.
(10:04:46) f13: tibbs: my proposal removes having to hack at the build system / release system to handle noarch ExcludeArch and ExclusiveArch and just make them arch specific.  They'll wind up in the same place as they did before, but they'll be .i386 vs .noarch