From Fedora Project Wiki
Fedora Packaging Committee Meeting of 2007.04.03
Present
- JasonTibbitts (
tibbs) - JesseKeating (
f13) - RalfCorsepius (
racor) - RexDieter (
rdieter) - TomCallaway (
spot) - VilleSkyttä (
scop)
Writeups
The following draft has been accepted by FESCO and is to be written into the guidelines:
- Modifications to the Naming Guidelines for handling non-numeric post-releases PackagingDrafts/PostRelease
- Mandating that filenames in RPMs be utf8: PackagingDrafts/Utf8Filenames
- Additional dist-related macros: PackagingDrafts/ExtraDistTagConditionalMacros
- Note that redhat-rpm-config is being updated to provide these macros. Currently the F7 version has them.
Votes
There were no votes this week.
Other Discussions
The issue of noarch packages which are not intended for all architectures was raised. A draft is being written and everyone is urged to contribute.
IRC Logs
[12:01] * spot is here
[12:03] * spot looks around
[12:04] * abadger1999 is here
[12:04] <racor> i am not quite here ;)
[12:04] <spot> f13, scop, tibbs, rdieter ?
[12:05] <scop> pong
[12:05] * rdieter wakes up, here!
[12:05] <f13> I'm here.
[12:05] <spot> well, this may be a very short meeting.
[12:06] <spot> item 1: FESCO ratified everything
[12:06] <spot> i
[12:06] <spot> i'll move all of the ratify items to writeup
[12:07] * rdieter likes short meetings...
[12:07] <spot> don't forget to announce the items when you write them up
[12:07] <spot> item 2: umm...
[12:07] <spot> well, lutter isn't here, but it doesn't seem like he's made any changes to his rubygems draft yet
[12:07] <rdieter> bummer.
[12:07] * scop didn't find round tuits for users/groups
[12:07] <spot> ok.
[12:08] <spot> those are the only two items on the todo list at the moment.
[12:08] <spot> does anyone have any items they'd like to bring up?
[12:08] <spot> (if no, say no)
[12:08] <rdieter> no
[12:08] <scop> no
[12:09] <f13> not exactly
[12:09] <spot> f13: what does that mean?
[12:09] <f13> I think we're going to get pressure to solve the stupid arch specific noarch packages crap
[12:09] <spot> you have something to bring up, but you wouldn't like to?
[12:09] <rdieter> ah, yes.
[12:09] <f13> but I'm afraid that it will mean either a lot of pain, or an rpm patch
[12:10] <tibbs> Ugh, sorry folks, I'm not feeling well today.
[12:10] <rdieter> f13: you don't like the pending proposal as-is?
[12:11] <f13> rdieter: I think not marking them as noarch has some bad side effects
[12:11] <f13> lots of wasted space
[12:11] <tibbs> Can we quantify "lots"?
[12:11] <rdieter> I think we'll just end up having to choose the lesser of two evils, which is it? :)
[12:12] <f13> rdieter: honestly? I think it's propagating the ExcludeArch or ExclusiveArch flags from the srpm into the resultant noarch rpm
[12:12] <f13> so that the rpm could be queried at compose / install time
[12:12] <rdieter> so... rpm patch is the prefered path, atm?
[12:13] <f13> but I say this without any knowledge if this is A) feasable or B) possible from the rpm perspective
[12:13] <f13> rdieter: I think so, but it also feels like punting the problem.
[12:13] <rdieter> what's wrong with just making these not .noarch? (more than just wasted space?)
[12:13] <rdieter> afaict, most the packages in question aren't really that big.
[12:14] <f13> I thought there was resistance, but I can't articulate what it was.
[12:14] <f13> I just don't feel good about it, since the packages themselves really are noarch
[12:14] <rdieter> seems to be the simpler band-aid, unless there are other issues at work here?
[12:15] <rdieter> I feel your pain, do we focus arch on *content* or *target*. tough call.
[12:16] <rdieter> maybe ping ml's for more feedback/comments? (not sure if that will help much, tho)
[12:16] <rdieter> what do others here think?
[12:17] * spot is rather indifferent
[12:17] <tibbs> One thing to keep in mind is noarch packages which depend on packages which aren't built on all platforms.
[12:17] <spot> i just want to make sure we don't arch specify without good reasons.
[12:18] <-- Bob-Laptop has left this server ("Leaving").
[12:18] <tibbs> This would come up most often with game data, which are often quite large.
[12:18] <scop> noarch "feels better"
[12:19] <f13> yes, the game data
[12:19] <scop> anyone thought about a shared noarch repo for all archs?
[12:19] <rdieter> scop: I think I feel the same way, .noarch for *content* feels better too.
[12:20] * spot would like to see a draft on this. it will need to cover several use cases
[12:20] <rdieter> fwiw, the kde-redhat repo uses a shared all/noarch repo, but it makes yum repo management uglier.
[12:21] <f13> scop: more repos suck more
[12:21] <rdieter> I've been thinking of ways to kill it off for some time...
[12:22] <scop> one more repo sucks more than duplicating/hardlinking packages in N repos?
[12:22] * rdieter agrees a draft would help, to list all the issues involved.
[12:22] <scop> and discussions like this?
[12:22] <scop> anyway, I'll take your word(s) for it
[12:23] <f13> scop: hardlinks make the space not an issue
[12:23] <f13> scop: the way that koji does things if a single package is tagged for multiple collections there aren't multiple copies of the package, only one.
[12:23] <rdieter> I don't think a separate repo helps solve the composing problem anyway...
[12:24] <scop> I was more pondering about shrugging off the problem altogether and having all noarch packages available for all archs
[12:24] <scop> but that's probably not acceptable
[12:25] <f13> scop: not without making things which require arch specific packages no longer noarch
[12:26] <rdieter> f13: and your definition of "arch specific packages" = not available for all archs?
[12:27] <rdieter> and it's not entirely clear (to me anyway) how yum handles/balks at arch -> noarch -> arch upgrade paths.
[12:28] <f13> rdieter: right, if something is not available for all arches, it wouldn't be noarch
[12:28] --> Bob-Laptop has joined this channel (n=Robert@fedora/pdpc.sustaining.BobJensen).
[12:28] <f13> if we went the route of target rather than content.
[12:29] <skvidal> rdieter: yum handles those fine
[12:29] <skvidal> arch->noarch->arch isn't a problem except for glibc and kernel
[12:29] <spot> even if something is noarch but totally irrelevant for an arch?
[12:29] <rdieter> skvidal: nice, thanks.
[12:29] <skvidal> spot: I'm not sure how yum would know that if it is in the repo
[12:30] <spot> skvidal: no, not regarding yum
[12:30] <spot> <f13> rdieter: right, if something is not available for all arches, it wouldn't be noarch
[12:30] <skvidal> oh, sorry
[12:30] <spot> sparc-afbinit-firmware.noarch
[12:30] <f13> ipw2200-firmware.noarch (:
[12:30] <f13> won't see those on say s390
[12:30] <spot> f13: totally useless on sparc.
[12:31] <spot> thus, can't be noarch?
[12:31] <tibbs> SPARC has no PCI?
[12:31] <spot> tibbs: you can't get ipw2200 non-embedded.
[12:31] <f13> it all depends on if we treat "noarch" as either content of hte package, or target for the package
[12:31] * rdieter nods.
[12:32] <rdieter> If we can agree on that, an implementation can follow.
[12:32] <f13> right now we're treating it somewhat as both
[12:32] <f13> but not quite
[12:33] <rdieter> my gut common-sense tells me content. *shrug*.
[12:33] <spot> is it really a place where we don't want to examine each package on a case by case basis?
[12:33] <spot> s/we/packagers
[12:33] <rdieter> maybe/probably (at least until we come up with something better).
[12:34] <spot> either way, if someone feels strongly that we should swing one way or the other, i'd like to read a draft.
[12:34] <spot> "use common sense" isn't a guideline.
[12:34] <f13> I had a draft to stop calling these arch specific things noarch
[12:34] <f13> but now I'm not happy with it.
[12:34] <spot> f13: ok, work on it? :)
[12:35] <f13> spot: well, if rpm got patched, there wouldn't need to be a guideline
[12:35] <spot> f13: that's always fine, but outside the FPC scope.
[12:35] <f13> noarch with ExcludeArch would Just Work as the .noarch.rpm would have that information in the header
[12:35] <tibbs> I think the problem is that we say "noarch" but in many cases we mean "multi-arch".
[12:35] <rdieter> yes!
[12:35] <tibbs> Adding ".multiarch" packages is probably out of the question, though.
[12:35] <rdieter> mult-but-not-all-arch. :)
[12:37] <f13> well, we say noarch and we mean 'content has no arch'
[12:37] <f13> as well as (usually) 'content can be built on any arch'
[12:39] * spot will happily review the draft when its ready
[12:39] <spot> any other items for today? :)
[12:39] <rdieter> (still) no.
[12:39] <spot> ok. meeting over. tibbs, feel better. :)
[12:40] <tibbs> Thanks.
[12:40] <tibbs> Should be an easy writeup today.