From Fedora Project Wiki

Revision as of 03:20, 21 December 2008 by Wikibot (talk | contribs) (Packaging/Minutes20070403 moved to Packaging:Minutes20070403: Moving Packaging Pages to Packaging Namespace)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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:

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.