From Fedora Project Wiki

m (1 revision(s))
m (Packaging/Minutes20080408 moved to Packaging:Minutes20080408: Moving Packaging Pages to Packaging Namespace)
 
(No difference)

Latest revision as of 03:24, 21 December 2008

Fedora Packaging Committee Meeting of {2008-04-08}

Present

  • DominikMierzejewski (Rathann|work)
  • HansdeGoede (hansg)
  • JasonTibbitts (tibbs)
  • RalfCorsepius (racor)
  • RexDieter (rdieter)
  • TomCallaway (spot)
  • ToshioKuratomi (abadger1999)

Writeups

The following drafts have been accepted by FESCO and are to be written into the guidelines:

  • SysV-style initscript guidelines:

http://fedoraproject.org/wiki/Packaging/SysVInitScript

  • Java packaging guidelines:

http://fedoraproject.org/wiki/Packaging/Java

  • Eclipse plugin guidelines:

http://fedoraproject.org/wiki/Packaging/EclipsePlugins

  • GCJGuidelines:

http://fedoraproject.org/wiki/Packaging/GCJGuidelines


Votes

The following proposals were considered:

  • Revisiting the jpackagage naming exception
  • The original exception is at http://fedoraproject.org/wiki/Packaging/JPackagePolicy; the committee is revisiting the exception.
  • The committee requests from the Java group "a list of information as to why they need the jpp tag, specifically, how they're using it, by May 8th." The committee will revisit the issue then.
  • Accepted (5 - 0)
  • Voting for: tibbs abadger1999 spot rdieter hansg

Other Discussions

The meeting ended with a long discussion of the packaging of static libraries and the conditions under which static libraries are allowable in the -devel pacuage. This was triggered by the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=430545. There was no written proposal.

Next meeting 2008-04-22.

IRC Logs

[12:06]  *** rdieter sets the channel topic to "Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule".
[12:06]  <spot> abadger1999, racor, hansg, tibbs?
[12:06]  * hansg is present and ready
[12:07]  <abadger1999> I'm here
[12:07]  * tibbs here
[12:07]  --> Rathann has joined this channel (n=rathann@onizuka.greysector.net).
[12:07]  * Rathann present
[12:07]  <spot> ok, thats 6 of us.
[12:08]  --> caillon has joined this channel (n=caillon@75.147.7.113).
[12:08]  <spot> first item is about the FPC seats
[12:08]  <spot> right now, we have two open seats
[12:08]  <spot> we had an election to determine the first open seat
[12:08]  <spot> but two candidates came out in a tie for first
[12:08]  <tibbs> How convenient.
[12:08]  <spot> thus, it seems reasonable to offer both of them a seat. :)
[12:09]  <tibbs> +1 to that.
[12:09]  <abadger1999> +1
[12:09]  <Rathann> +1
[12:09]  <hansg> +1
[12:09]  <spot> +1
[12:09]  <rdieter> +1
[12:09]  <spot> ok, i will send them email today to invite them to join
[12:10]  <spot> now, lets get to the fun stuff
[12:10]  <tibbs> Well, first, who are the two new folks?
[12:10]  <tibbs> Or is it a secret until they accept?
[12:10]  <spot> well, i'd rather make sure they are still willing
[12:11]  <racor> sorry, for being late, and sorry in advance, I'll also have to quit early, today :/
[12:11]  <spot> first item of business: http://fedoraproject.org/wiki/PackagingDrafts/NoBitsInSrv
[12:11]  <tibbs> I wish we could handle this better.
[12:12]  <spot> tibbs: i wish the FHS wasn't such a trainwreck here.
[12:13]  <abadger1999> I like the quote.  Self-contradictions are always good for proving a point.
[12:13]  <spot> if the FHS ever gets its head out of its ass here, we'll draft proper usage guidelines for /srv
[12:13]  <tibbs> Well, yeah.  I guess in the absense of useful guidance we just have to stay clear of it.
[12:14]  <tibbs> +1 to the draft, although I've no idea how to go about fixing things.
[12:14]  <abadger1999> So what's the plan for migration from F-9 w/ /srv usage to F-10 without?
[12:14]  <spot> abadger1999: i'll file bugs and work with the packagers on a case-by-case
[12:14]  <tibbs> The thing that really bothers me is that if we could just fix a structure for /srv, we could have working selinux rules for that content.
[12:15]  <tibbs> Right now you have to know too much about selinux in order to move your web sites out of /var, for example.
[12:15]  <Rathann> tibbs: wouldn't mount --bind work around that?
[12:16]  * spot is +1 on this draft (since it is one of mine)
[12:16]  <Rathann> +1 from me too
[12:16]  <abadger1999> +1
[12:16]  <racor> +1
[12:16]  <abadger1999> If we run into problems porting I'm sure you'll let us know.
[12:16]  <Rathann> tibbs: it says "at this time", we can revisit it later
[12:17]  <tibbs> Rathann: Yes, it is always the case that we can revisit guidelines.
[12:17]  <spot> ok, thats a +5... hansg, if you'd like a vote on the record, feel free to chime in.
[12:17]  <hansg> +1
[12:18]  <spot> next item: http://fedoraproject.org/wiki/PackagingDrafts/ASCIINamingLowercase
[12:18]  <rdieter> +1 nobitsinsrv (too)
[12:18]  <tibbs> -1
[12:18]  * spot notes that "Even historic mixed-case packages like X have been converted to lowercase over time." is pretty much false.
[12:18]  <racor> -10
[12:18]  <spot> -1
[12:19]  <spot> well, if others would like to vote here, they can go on the record
[12:19]  <Rathann> 0
[12:19]  <hansg> -1
[12:19]  <spot> but this one is pretty much dead.
[12:20]  <abadger1999> +1
[12:20]  <rdieter> while I tend to agree with the sentiment of this proposal, it's implementation, wording isn't acceptable.
[12:20]  <abadger1999> :-)
[12:20]  <abadger1999> rdieter: Agreed
[12:20]  <rdieter> 0
[12:20]  <spot> OK, lets move on. Next item: Revoke JPackage Naming Exception
[12:20]  <spot> Specifically, I propose that we revoke: http://fedoraproject.org/wiki/Packaging/JPackagePolicy
[12:20]  <hansg> I could live with a rule saying that mixed case package names should have an all lowercase provides for easy yum install foo instead of yum install fOo
[12:21]  <spot> the arguments in that exception policy were ... tenuous at best.
[12:21]  <tibbs> hansg: I agree; I would also be happy with a rule about whether you can have two packages whose names differ only in case.
[12:22]  <hansg> -1 (to revoking it) seing the discussion on the devel-list, there doesn't seem to be a consensus on this in our community
[12:22]  <spot> no progress has been made by anyone to work towards improving the areas of concern, but there has also been no serious loss to anyone as a result of their absense.
[12:22]  <tibbs> spot: I agree about the jpackage naming policy, but as far as I know we still haven't received that information about why it's actually needed.
[12:22]  <spot> tibbs: indeed. I don't think we're ever going to get any.
[12:22]  <tibbs> Well, I don't want to go revoking it without understanding why it's actually needed.
[12:22]  <hansg> I agree it isn't completely pretty, but revoking it nw can only result in bad blood between Fedora and jpackage, which is not something I want
[12:22]  <tibbs> But then again, they can just not submit the requested information.
[12:23]  <spot> other than to perform "group exclusions", which no one seems to actually use.
[12:23]  <tibbs> So what we need is a deadline, I think.
[12:23]  <rdieter> tibbs: nod, put the onus on justifying the exception... or else. :)
[12:24]  * spot proposes April 30th, 2008
[12:24]  <tibbs> "The exception will expire automatically on <date> unless we're presented with sufficient information to consider extending it."
[12:24]  <spot> that should be plenty of time.
[12:25]  <spot> +1 to the deadline for requested information
[12:25]  <tibbs> We should be meeting on May 6th; how about that as a deadline?
[12:25]  <spot> ok.
[12:25]  <abadger1999> How would reasons differ from what's already there?
[12:25]  <tibbs> It also gives them four full weeks.
[12:26]  <tibbs> abadger1999: There was a conference call wherein this was discussed.  Several reasons were mentioned which I had not heard of before.
[12:26]  <abadger1999> Okay.
[12:26]  <spot> abadger1999: well, the reasons already there... they're... umm... not terribly believable.
[12:26]  <tibbs> One of the action items from that call was that Fernando Nasser would write up something indicating why this is necessary.
[12:26]  <-- Kevin_Kofler has left this channel ("Bye!").
[12:26]  <abadger1999> spot: Very true but we accepted them when we passed it the first time.
[12:26]  <tibbs> That call was about a month ago.
[12:26]  <tibbs> abadger1999: Well, we accepted them temporarily.
[12:27]  <abadger1999> We accepted the exception emporarily.
[12:27]  <spot> abadger1999: yes, but we accepted it on the grounds that they would work on workarounds.
[12:27]  <abadger1999> But we accepted the rationale as true.
[12:27]  <spot> no work whatsoever has been done.
[12:27]  <spot> this either means that A) they have no intentions of using proper workarounds
[12:27]  <spot> or B) these concerns are not realistic.
[12:28]  <racor> spot: who is they? jpp or the Fedora folks integrating java?
[12:28]  <spot> racor: the Fedora folks integrating java
[12:28]  <abadger1999> spot: Okay.  Then deadline is a good thing.  Should it be a deadline for new information or a deadline for work to be done on existing information?
[12:29]  * hansg would like to see more cross (rpm based) distro collaboration not less
[12:29]  <spot> abadger1999: i think a list of information as to why they need the jpp tag, specifically, how they're using it.
[12:29]  <abadger1999> +1
[12:29]  <racor> spot: OK, IMO, then we should not set them a deadline, but change the rules.
[12:29]  * Rathann wonders what those "grouped operations on all the Java packages" are...
[12:29]  <racor> rationale: jpp is an external repo, not of any busines with fedora
[12:29]  <hansg> I think in the sense of cross distro collaboration we should see jpackage as upstream, and see our own mods as bugfixes to that upstream, which we then merge back upstream
[12:30]  <spot> racor: i'd like to see the JPackage folks drop the tag, but thats their business.
[12:30]  <spot> hansg: except that we're acting more like a weird fork of jpp
[12:30]  <hansg> The current scheme with a fedora specific version after the jpp tag nicely reflects this upstream <-> downstream release, and gives clear info on which upstream release our release is based on
[12:31]  <racor> spot: jpp is not our business, Fedora is our business and concern.
[12:31]  <spot> racor: indeed.
[12:31]  <Rathann> hansg: I think URL: is enough of an upstream indicator
[12:31]  <hansg> racor: thats a rather narrow view
[12:31]  <Rathann> we don't need to put it in %{release}, too
[12:31]  <spot> hansg: perhaps we should tag "gnome" on everything from GNOME?
[12:31]  <hansg> Rathann ?? URL should point to the _real_ upstream, not to jpackage
[12:31]  <Rathann> exactly
[12:32]  <Rathann> oh
[12:32]  <Rathann> right
[12:32]  <hansg> Spot: No, but we don't remove part of their versioning either because we find it ugly
[12:33]  <spot> hansg: its not in their versioning
[12:33]  <racor> sorry guys, dinner is waiting, I got to quit .. (DST hits)
[12:33]  <spot> jpackage is no more of an upstream than Fedora is.
[12:33]  <caillon> we don't use gnome specfiles which sometimes have different release versions, e.g. .jh
[12:33]  <spot> and when these packages go into Fedora, they're Fedora packages.
[12:34]  <hansg> "and when these packages go into Fedora, they're Fedora packages", that doesn't sound like a cross fistro collaboration view of things, not _at all_
[12:34]  <tibbs> Also, keep in mind that the reasons I heard about in the conference call didn't have anything to do with upstreams or interlacing jpackage versioning with Fedora versioning.
[12:34]  <Rathann> hansg: well, how does suse or mandriva handle this?
[12:34]  <hansg> Why should every tpm based distro do its own fork of java packages?
[12:34]  <hansg> s/tpm/rpm/
[12:34]  <spot> or kernel, or glibc, or X
[12:34]  <hansg> if we can avoid that, that would be a big win!
[12:35]  <spot> the simple fact is that all distributions package differently
[12:35]  <hansg> Rathann, I have no idea
[12:35]  <abadger1999> hansg: The one thing I don't like about the jpackage naming is that it is built around making the Fedora package interleave with the JPackage packages. That means that local changes to make a particular package work in Fedora will be reverted when JPackage releases a new version.
[12:35]  <spot> i doubt strongly that OpenSUSE would take packages where a "fedora" tag was forced on them.
[12:36]  <hansg> Yes, but java code depends on a jre, not an OS, so it should be possible (and this has been show) todo pretty distro agnostic packages
[12:36]  <spot> hansg: so, if they're distribution agnostic, why the jpp tag?
[12:36]  <spot> why do we care where they came from?
[12:36]  <spot> they should be properly maintained inside the Fedora repo.
[12:36]  <tibbs> Also, if they're distro-agnostic, then fine, they're not something to be considered by this committee.
[12:37]  <tibbs> But if they'\re in Fedora, then they should be regular Fedora packages.
[12:37]  <abadger1999> hansg: Not entirely true.  For instance filesystem placement, gcj compilation....
[12:37]  <Rathann> suse doesn't seem to have any packages with jpp in the release
[12:37]  <Rathann> at least in the official repos
[12:38]  <hansg> About the interleaving, don't think of it as interleaving. Think of it as version versus release, version should always win, anyways I'm clearly in the minority here, so I'll shut up now
[12:38]  * spot feels like we're going in circles here
[12:38]  <Rathann> +1 to the jpp draft from me
[12:38]  <abadger1999> hansg: version doesn't always win.
[12:39]  <abadger1999> hansg: version wins when there's another Fedora package with a higher version.
[12:39]  <hansg> abadger1999, it does over release
[12:39]  <abadger1999> hansg: It doesn't win when there's an upstream version with a higher version than the Fedora Package.
[12:39]  <spot> I propose that we ask specifically for a list of information as to why they need the jpp tag, specifically, how they're using it, by May 8th.
[12:39]  <abadger1999> amend that to: We don't support or encourage it to win.
[12:39]  <tibbs> spot +1
[12:39]  <hansg> unless a 3th party repo which has this version is activated, which is the exact scenario which can be the case with jpackage
[12:40]  <spot> We'll revisit this at that point, with that data in hand (or not).
[12:40]  <abadger1999> (As rpm will happily upgrade foo-1.0-fedora.rpm with random.sf.net/foo-1.1.rpm but we are very much against supporting the pieces in that case.)
[12:41]  <abadger1999> +1
[12:41]  <spot> +1
[12:41]  <rdieter> +1
[12:41]  <hansg> 0
[12:41]  <tibbs> hansg: So you don't support asking for more information?
[12:42]  <hansg> Not with a gun to their head added to it, no
[12:42]  <f13> hansg: we've been waiting 2~ years now fo this information
[12:42]  <f13> hansg: without some sort of motivation, I don't believe we'll ever get it
[12:42]  <tibbs> Simply talking about it again in a month is holding a gun to their head?
[12:42]  <tibbs> Wow.
[12:43]  <Rathann> according to rpmdev-vercmp foo-1.0-1jpp is older than foo-1.0-1.1 and foo-1.0-2jpp is newer than foo-1.0-1.1
[12:43]  <rdieter> dropping the exception without receiving new information, *is* a gun, of sorts.
[12:43]  <spot> Rathann: this is why you shouldn't put alpha characters randomly into release. :P
[12:43]  <Rathann> so for all intents and purposes, we can drop jpp from our release but keep the number that precedes it
[12:43]  <tibbs> rdieter: Where was that in spot's proposal?
[12:43]  <hansg> tibbs, quoting you from this irc meeting:  "The exception will expire automatically on <date> unless we're presented with sufficient information to consider extending it."
[12:43]  <hansg> So yes thats a gun to their head
[12:43]  <tibbs> That was me.
[12:43]  <f13> Rathann: that was the proposal I came up with over a year ago, which has fallen on deaf jpackage ears.
[12:43]  <spot> all i am proposing is:
[12:43]  <tibbs> That wasn't spot's proposal.
[12:44]  <spot> I propose that we ask specifically for a list of information as to why they need the jpp tag, specifically, how they're using it, by May 8th.
[12:44]  <rdieter> ok
[12:44]  <spot> We'll revisit this at that point, with that data in hand (or not).
[12:44]  <hansg> In that case, spot +1
[12:44]  <spot> ok, thats a +5.
[12:44]  <Rathann> f13: it was a good proposal :)
[12:44]  <spot> abadger1999: javascript isn't ready, i assume?
[12:45]  <abadger1999> spot: No.  Not enough feedback.
[12:45]  <spot> Fair enough. Next item: http://fedoraproject.org/wiki/DennisGilmore/SugarActivityGuidelines
[12:45]  <abadger1999> Unless someone here has ideas,I'll draft something, send it to the list, and see if I can get someone to at least flame it.
[12:46]  <tibbs> Are these sugar activities always noarch?
[12:47]  <Rathann> hm, python-only -> noarch? can't it contain some binary bits?
[12:47]  <abadger1999> Lokspretty good.
[12:47]  <abadger1999> tibbs: "Architecture-specific Activities" [...] 
[12:47]  <hansg> Hmm, I don like: "%define sugaractivitydir /usr/share/activities/"
[12:47]  <tibbs> Yeah, but above says they always go in /usr/share/activities
[12:47]  <tibbs> If arch-specific, that would be bad.
[12:48]  <Rathann> indeed
[12:48]  <spot> dgilmore: ping
[12:48]  <abadger1999> Rathann: Maybe we should clarify that.  I took it to mean, no C extensions for the python module.
[12:48]  <hansg> Hmm, I hadn't even looked at that (arch specific under /usr/share)
[12:48]  <Rathann> abadger1999: ok, but are they always noarch?
[12:49]  <hansg> I find /usr/share/activities a bit to generic, why not /usr/share/sugar/activities
[12:49]  <tibbs> Well, it says that they don't have to be.
[12:49]  <Rathann> if yes, then why python-only should be noarch?
[12:49]  <abadger1999> Good catch, tibbs
[12:49]  <hansg> What if another framework comes around which also has activities, why this claim on the global %{_datadir} namespace?
[12:49]  <caillon> spot, btw, i'd like to ask for clarification on one item with f9 impact if there's time today
[12:50]  *** knurd is now known as knurd_afk.
[12:50]  <spot> caillon: ok...
[12:50]  <tibbs> I agree that /usr/share/activities is a bit generic.
[12:50]  <spot> since dennis isn't around, i'll ask him for clarification here
[12:50]  <spot> and we'll revisit it in two weeks
[12:50]  <hansg> We also have all these too generic kde stuff directly under %{_datadir} while they really belong under %{_datadir}/kde
[12:51]  <spot> Next item: http://fedoraproject.org/wiki/PackagingDrafts/ConditionalGCJ
[12:51]  <abadger1999> I wonder if that's changable on OLPC.  I wonder if we can have a different value for the macro on OLPC builds vs Fedora builds if it isn't/
[12:51]  <spot> basically, this draft argues that whenever gcj is used, it should be conditionalized.
[12:51]  <hansg> abadger1999, I wonder the same, if it isn't changeable I guess we will have to live with it, grumble
[12:52]  <Rathann> it's another copy&paste bit to put into specfiles
[12:52]  <spot> this means that you can't have a package with gcj and noarch bits together.
[12:52]  <Rathann> I don't like it very much, but I'm not opposed
[12:52]  <Rathann> I wish it could be handled with an rpm macro
[12:53]  <tibbs> This is certainly simpler than the conditionals I've seen from some java packages.
[12:53]  <spot> well, i take it back, i suppose it just enables the gcj bits with the conditional
[12:53]  <abadger1999> spot: Actually, that was already the case, righyT?
[12:53]  <rdieter> spot: why not?  (or maybe we don't want to encourage the koji can build pkgs as both arch and noarch hack)
[12:53]  <abadger1999> rigt.
[12:53]  <tibbs> But isn't there a bcond macro that does this?
[12:53]  <dgilmore> spot: pong
[12:54]  <spot> dgilmore: we had a few concerns about the sugaractivities draft
[12:54]  <dgilmore> spot: shoot
[12:54]  <spot> dgilmore: 1. /usr/share/activities is very generic
[12:54]  <spot> dgilmore: is that something OLPC depends on, or could it be /usr/share/sugar/activities ?
[12:54]  <dgilmore> spot: thats where sugar looks for activities  there and ~/Activities
[12:55]  <dgilmore> spot: it could be changed but will take time
[12:55]  <spot> ok, 2. What about architecture specific activities?
[12:55]  <spot> they shouldn't go in /usr/share
[12:56]  <dgilmore> an example of an architecture specific activity is simcity
[12:56]  <spot> where does it live currently?
[12:56]  <dgilmore> /usr/share/activities/SimCity.activity/
[12:56]  <spot> hrm. that seems like it really isn't right.
[12:57]  <spot> i think we'd want a %{_libdir}/activities (at a minimum)
[12:57]  <spot> although, i'm not sure if OLPC will buy off on that
[12:58]  <spot> since OLPC has no multilib concerns
[12:58]  <Rathann> well, Fedora does have them
[12:58]  <dgilmore> there is a python wrapper for all activities
[12:59]  <dgilmore> even arch specific ones
[12:59]  <spot> dgilmore: yes, but the arch specific bits really don't belong under /usr/share
[12:59]  <spot> the FHS says no. :/
[13:00]  <spot> dgilmore: let's think about this some more and table it for now
[13:00]  <dgilmore> all the examples i can think of that are arch specific should run ok outside of sugar
[13:00]  <spot> ok FPC folks, can we vote on the http://fedoraproject.org/wiki/PackagingDrafts/ConditionalGCJ ?
[13:00]  <abadger1999> +1
[13:00]  <spot> +1
[13:00]  <tibbs> +1
[13:00]  <rdieter> +1
[13:01]  <hansg> Why _must_ the use of gcj be made conditional?
[13:01]  <spot> hansg: so that it can be disabled for local builds.
[13:01]  <tibbs> Although if anyone understands the bcond macros, I'd like to know why they aren't used here.
[13:01]  <f13> hansg: one reason, enables spec sharing between Fedora and jpp
[13:01]  <Rathann> +1, with comments above :)
[13:01]  <hansg> I don't like conditionals, esp not these style, weren't we supposed to have something better then this now?
[13:01]  <Rathann> tibbs: are they present in EL-4?
[13:02]  <tibbs> This draft basically eliminates one difference between Fedora and jpackage guidelines.
[13:02]  <spot> well, thats a +5, so this passes.
[13:02]  <hansg> Ok, I understand the why now, and I see that this is good to have
[13:03]  <spot> caillon: you had something for today? go ahead.
[13:03]  <tibbs> Rathann: I cannot answer that question.
[13:03]  <Rathann> one more question, why >= 1.0.31?
[13:03]  <caillon> spot, wanted clarification on https://bugzilla.redhat.com/show_bug.cgi?id=430545
[13:03]  <Rathann> or is that taken from jpackage as well?
[13:03]  <hansg> http://fedoraproject.org/wiki/PackagingDrafts/ConditionalGCJ +1
[13:03]  <caillon> spot, the static issue there in the last few comments
[13:04]  <tibbs> Rathann: I imagine there is some version specific dependency; I guess you'd have to see what changed in that version to enable this kind of thing.
[13:05]  <spot> caillon: so, does SDL depend on that static library?
[13:05]  <tibbs> caillon: That's an interesting issue we didn't consider.
[13:05]  <Rathann> the solution in comment #11 isn't good
[13:05]  <Rathann> it violates packaging guidelines
[13:05]  <f13> I don't get the issue.  Why can't the -static subpackage require the -devel subpackage?
[13:06]  <Rathann> f13: it should require it, I think
[13:06]  <hansg> AFAIK, SDLmain shouldn't be used on Unix at all, its a windows thing which does the necessary dll loading (windows dynamic linking stinks?)
[13:06]  <Rathann> as with any -static package
[13:06]  <caillon> spot, i'm not the SDL guy, just someone trying to rebuild things against GCC 4.3... but AIUI SDL doesn't require it, but pretty much anything that BR SDL does
[13:06]  <spot> i think the solution is for packages to properly BuildRequire: SDL-static if they really need it.
[13:06]  <Rathann> the question is, does every sdl app need that libSDLmain.a to build?
[13:06]  <Rathann> if not, what spot just said is my proposal as well
[13:07]  <spot> hansg: you do more SDL than I do...
[13:07]  <spot> caillon: wouldn't lots of other stuff be breaking here if that was the case?
[13:07]  <rdieter> since libSDLmain.a is static only, including it in -devel is (should be!) ok.
[13:08]  <caillon> spot, no idea :)
[13:08]  <Rathann> rdieter: I disagree (if it isn't needed to build ALL SDL apps)
[13:08]  <f13> rdieter: that's now how I read the guidelines
[13:08]  <spot> rdieter: no, i'm pretty sure it needs to be in a -static
[13:08]  <f13> rdieter: if sdl-devel were entirely made up of just static libraries, thenit could be -devel.
[13:08]  <hansg> I maintain tons of SDL packages and non require SDLmain, using that under unix is in general ill advised, it isn't needed. It does some magic to hide main vs winmain for windows compatibility and more ugliness like that
[13:09]  <f13> but since there is both shared /and/ static libraries (not all the same) there needs to be a -static subpackage.
[13:09]  <rdieter> shrug, that's just my interpretation and intent of those guidelines.
[13:09]  <hansg> [hans@localhost ~] $ sdl-config --libs
[13:09]  <Rathann> so, IOW, whatever uses libSDLmain.a should be fixed not to use it?
[13:09]  <spot> caillon: well, it seems like packages that need that package should properly BR and R it.
[13:09]  <hansg> -lSDL -lpthread
[13:09]  <abadger1999> If it's necesssary then I think we want a subpackage
[13:09]  <hansg> Notice how there is no -lSDLmain there
[13:09]  <f13> hrm.
[13:09]  <Rathann> hansg: well, it IS static only
[13:09]  <f13> sounds like it should be dropped all together, and the offending packages built.
[13:09]  <abadger1999> subpackage for SDLmain that is.
[13:09]  <f13> s/built/fixed/
[13:09]  <Rathann> hansg: no reason for it to show up there
[13:09]  <rdieter> there's qt4 as well as a few kde packages are in violation then.
[13:09]  <hansg> Erm
[13:10]  <hansg> allegro-config --libs
[13:10]  <abadger1999> Then it can have a -static or -devel independent of SDL.
[13:10]  <hansg> -Wl,--export-dynamic -lalleg-4.2.2 -lalleg_unsharable
[13:10]  <tibbs> We should first consider the intent of the static guideline, and then apply that intent to the package in question.
[13:10]  <hansg> alleg_unsharable is static too
[13:11]  <f13> tibbs: I do believe the intent was to isolate the static libs and campaign to remove them all together
[13:11]  <tibbs> The point was that any application which uses a static library should have a dependency on the -static package so we can find them and rebuild them if necessary.
[13:11]  <hansg> f13: I think that would be a good solution yes
[13:11]  <f13> tibbs: and also to be able to find when things require static libs, so when we update a static lib, the other things get rebuilt so that they aren't continually vulnerable in their static copy.
[13:11]  <hansg> But since F-9 is close, I guess we can just move SDLmain.a to -devel
[13:11]  <tibbs> The exception about putting them in -devel was to avoid having a pointless -devel package with no libraries.
[13:11]  * f13 agrees with tibbs
[13:11]  --> Kevin_Kofler has joined this channel (n=Kevin_Ko@chello213047068123.17.14.vie.surfer.at).
[13:12]  <tibbs> So, how does that apply to this case?
[13:12]  * spot remains unsure as to why this package which needs this SDL-static lib can't just use BuildRequires: SDL-static, SDL-devel
[13:12]  <tibbs> Does the package in question need the static library?
[13:12]  <hansg> tibbs, AFAIK yes
[13:12]  <Kevin_Kofler> libSDLmain.a contains the main() function.
[13:12]  <Kevin_Kofler> A program without a main() function won't run...
[13:12]  <tibbs> Then it should depend on the -static package at build time.
[13:12]  <tibbs> So what issue remains?
[13:13]  <Kevin_Kofler> The guidelines say:
[13:13]  <Kevin_Kofler> > If a library you depend on _only_ provides a static version your package can
[13:13]  <Kevin_Kofler> > link against it provided that you BuildRequire the *-devel subpackage.
[13:13]  <Kevin_Kofler> not the *-static one.
[13:13]  <f13> Kevin_Kofler: that seems counter to what hansg has just been saying.
[13:13]  <hansg> No, Kevin is right.
[13:13]  <f13> hansg: you were just saying it wasn't needed!
[13:14]  <spot> so, if we fix that to say "If a library you depend on _only_ provides a static version your package can link against it provided that you BuildRequire both the *-devel and the *-static subpackage."
[13:14]  <f13> Kevin_Kofler: ah, I think that's poorly worded.
[13:14]  <abadger1999> spot: No
[13:14]  <hansg> Here is how it _normally_ works, an SDL app has a normal main(), and on windows that gets #defined to SDLmain with SDLmain.a providing the real main
[13:14]  <abadger1999> I think that defeats the intention of that wording.
[13:15]  <abadger1999> The intention was, when/if a dynamic version appears, the next rebuild will do the right thing and link dynamically.
[13:15]  <rdieter> abadger1999: +1!
[13:15]  <f13> spot: I think it should be: "If a library package you depend on _only_ provides static libraries, your package can link against it provided that you BuildRequire the -devel suppackage"
[13:15]  <hansg> However some applications have trouble with the #define because of the way they prototype their main, this can be solved by doing the renaming in the source instead of letting the preprocessor do it
[13:15]  <tibbs> Kevin_Kofler: The quote from the guidelines above do not seem to be correct.
[13:15]  <Rathann> hm, right, but in this case there won't be a next version with dynamic lib
[13:15]  <hansg> in this case the app will need SDLmain.a on other platforms too
[13:15]  <tibbs> At least, I can't see where you pasted that from.
[13:16]  <Kevin_Kofler> From the page which says that FESCo approval is needed for BRing *-static.
[13:16]  <f13> Kevin_Kofler: I think that snippit only applies when the library package in question only has static, there are no shared libraries whatsoever, which isn't hte case with SDL
[13:16]  <tibbs> The guidelines themselves seem quite clear on this to me.
[13:16]  <caillon> Kevin_Kofler, btw, not sure why i didn't think of pinging you about this, but thanks for joining anyway.  you know more about this than i do.  :)
[13:16]  <tibbs> I'm not really sure that there's a question here that isn't answered by the guidelines themselves.
[13:16]  <hansg> To me the solution is quite simple, since there is no dynamic SDLmain, the static one may and should go in the normal -devel
[13:17]  <spot> tibbs: yeah, i agree. i'm not sure where that wording came from.
[13:17]  <Kevin_Kofler> Here's the source: http://fedoraproject.org/wiki/Packaging/Guidelines#head-ed9c4b45be77361033ccbc199bb3d49d02283ba9
[13:17]  <spot> hansg: no, thats really not right.
[13:17]  <Rathann> obviously libSDLmain.a is a special case
[13:17]  <f13> so, what I'm really missing, is what is the complaint?  If SDL is following the guidelines, and it seems it is by havinging -devel for shared, and -static for the statics, what is the problem?
[13:17]  <hansg> spot, why not?
[13:17]  <Rathann> hansg: that's the simple solution
[13:17]  <Kevin_Kofler> spot: It comes from a page you maintain. ;-)
[13:17]  <spot> Kevin_Kofler: i probably even wrote it.
[13:17]  <tibbs> Kevin_Kofler: The text that you quoted above is not present at the url you just gave.
[13:18]  <spot> tibbs: "If a library you depend on only provides a static version your package can link against it provided that you BuildRequire the *-devel subpackage. BuildRequiring *-devel causes your package to link against the dynamic version once the library starts providing one and your package is rebuilt."
[13:18]  <hansg> f13, " havinging -devel for shared, and -static for the statics" only applies when there are both versions of a lib, in the libSDLmain case there only is a static version
[13:18]  <spot> tibbs: its there
[13:18]  <Kevin_Kofler> The "not the *-static one" text isn't there, but that wasn't a quote.
[13:18]  <tibbs> That means that you buildrequire both the -static and the -devel packages.
[13:19]  <Rathann> I propose a separate SDL-devel-SDLmain package with the problematic library only
[13:19]  <f13> hansg: no, you're talking about versions of individual library files, whereas the guidelines are talking about /any/ shared, vs /any/ static.
[13:19]  <spot> tibbs: which does defeat the point, but its the best solution i see
[13:19]  <tibbs> Crap, or am I confused now?
[13:19]  <hansg> f13 are they?
[13:19]  <abadger1999> Rathann: +1
[13:19]  <f13> hansg: that was my understanding.
[13:19]  <rdieter> f13: I'd rather clarify the guidelines to say something like "in the case of *both* shared and static versions of a library are provided, the static one should go in -static"
[13:19]  <abadger1999> Rathann: Maybe SDL-SDLmain-devel, though
[13:19]  <hansg> But that it is not why they literary say!
[13:20]  <Kevin_Kofler> FWIW, rdieter's proposal is what I've been arguing for in the bug report.
[13:20]  <f13> hansg: which is why we have humans to parse them and adjust them for clarity.
[13:20]  <Rathann> abadger1999: I wasn't sure about the name :)
[13:20]  <hansg> And the logical thing would be to put SDLmain.a in -devel, as when there are only static libs, we put them in -devel
[13:20]  <spot> So, there are two use cases:
[13:20]  <f13> hansg: the intent may be different than the literal translation.
[13:20]  <tibbs> Unfortunately IRC really isn't the place for this.
[13:20]  <spot> 1. static libs and dynamic libs
[13:20]  <rdieter> hansg: +1
[13:20]  <spot> 2. static libs only
[13:20]  <f13> spot: 3.
[13:20]  <tibbs> In the past we've said that we'd only address written drafts here, and I guess this is what happens when we go off-script.
[13:20]  <f13> static libs of one library only, dynamic libs of different libraries in the same package.
[13:21]  *** gregdek is now known as gregdek_gone.
[13:21]  <rdieter> f13: foreach lib in *.so *.a ; case 1 2 ; done
[13:21]  <thm> problem is the guidelines think of a single library (static or dynamic) per package
[13:21]  <Rathann> yeah, we should continue this on fedora-packaging
[13:21]  <abadger1999> What about subpackage?  Both Rathann and I have suggested it.
[13:22]  <spot> abadger1999: would violate the guidelines as written.
[13:22]  <rdieter> abadger1999: -1 needless complication (and I'd rather sort out the guidelines intention first)
[13:22]  <f13> rdieter: so again, I feel you're trying to apply the 'package' guidelines to individual 'files'.  I don't believe that was the original intent of the guidelines
[13:22]  <f13> rdieter: as now, if you just BR the -devel package, we have no way of knowing that you actually used static libraries.
[13:22]  <rdieter> f13: ok, I guess we just disagree then. :)
[13:22]  <abadger1999> spot: Depends on your definition of "package" I guess.
[13:22]  <spot> this is almost getting Clintonesque.
[13:22]  <abadger1999> (I've gotten in trouble for that before as hans canattest :-/)
[13:23]  <spot> the idea behind the -static package was this
[13:23]  <spot> we could track packages that used static libraries by looking at BuildRequires
[13:23]  <rdieter> f13: right, my intention was -static let's you know if static libs were used, but shlibs were available.
[13:23]  <spot> if SDL packages need this static library, great, let them BR it.
[13:24]  <spot> lots of SDL packages don't need it.
[13:24]  * hansg isholding a crying baby now so don't exprvt much input from me atm
[13:24]  <rdieter> that's it! we made the baby cry. stop now. :)
[13:24]  <f13> I have no voting power, but I agree with spot
[13:25]  <rdieter> I just think forcing  -static  pkgs for which there are no shlib equivalents is a little silly.
[13:25]  <f13> caillon: question, what is the F9 impact here?
[13:25]  <spot> i agree that the static section could use some clarification (and possibly simplification), but the spirit of putting static bits in -static whenever any dynamic libs (whether they are a whole set replacement or not) are present.
[13:26]  <caillon> f13, several gcc rebuild failures depend on SDLmain.a
[13:26]  <f13> rdieter: if you brought the static into -devel, -devel would have to provide -static, and then /every/ SDL app would pop as having "static" requirements.
[13:26]  * hansg just realizes this applies to allegro too
[13:26]  <f13> rdieter: it would ruin our ability to track the things that really do require static libraries.
[13:26]  <Rathann> the way I see it, puting it in -devel defeats the intent of keeping static libs separate and putting it in -static may make a package linking against it link static versions of other SDL shared libs
[13:27]  <Rathann> hence my and abadger1999's proposal seems sane
[13:27]  <rdieter> f13: sorry, being selfish thinking as packager only here.  it's an increased burden by changing what I thought the intention was.
[13:27]  <rdieter> I thought the intention was to simplify things for packagers (mostly)
[13:27]  <f13> rdieter: this is.
[13:27]  <hansg> allegro has a liballeg_unsharable which contains non pic asm code liballeg.so needs
[13:27]  <rdieter> not primarily be a means of tracking where static libs were being used.
[13:28]  <f13> rdieter: it helps the maintianer realize with a static library they require changes.
[13:28]  * spot thinks about Rathann's point
[13:28]  <f13> rdieter: if we just chuck the static library in the same package with all the other shared libraries, it increases the difficulty to track just static changes.
[13:28]  <rdieter> f13: but if they BR: foo-devel foo-static, they'll never notice.
[13:29]  <f13> rdieter: yes they will, because of the -static, and because they'll have to be on the initialcc of the package.
[13:29]  <Rathann> make it SDL-SDLmain-static if you want to have -static in the name
[13:29]  <spot> i would rather have a package linking against 99% shared and 1% static than 100 static
[13:29]  <hansg> -1 to a seperate subpackage
[13:29]  <f13> hansg: is there a way to prevent it from static linking to the rest of the static libs?
[13:29]  <hansg> SDLmain.a belongs in -devel, as there is no shared equivalent
[13:30]  <rdieter> hansg: seems we're in the minority on that viewpoint.
[13:30]  <hansg> f13, I've lost you here, need more context
[13:30]  <spot> well, if we make the case that static libraries with no shared library equivalent stay in -devel...
[13:31]  <spot> if they ever grew a shared library equivalent, they'd need to move into -static
[13:31]  <hansg> spot +1
[13:31]  <f13> hansg: if we were to put main.a in -devel, the -devel subpackage would have to grow a Provides: -static.  Then everybody BRing -devel would suddenly trigger as requiring "static" libraries
[13:31]  <rdieter> yes
[13:31]  <spot> but we wouldn't need a -static Requires in -devel
[13:31]  <Rathann> if a bug is found in libSDLmain, you need to rebuild all packages which BRequire it anyway
[13:31]  <hansg> f13 why?
[13:31]  <f13> spot: which would then trigger false positives on repo searches
[13:31]  <abadger1999> hansg: Yes it belongs in a -devel.  No it does not belong in SDL-devel.
[13:31]  <spot> f13: i'm not sure I understand this
[13:31]  <f13> hansg: there is now way to tell "I BR foo-devel for the shared, not for the static in there" vs "I BR foo-devel for the static"
[13:32]  <Rathann> how do you know which packages are linked against libSDLmain.a?
[13:32]  <spot> we're way overtime here.
[13:32]  <spot> i'll try to come up with a draft here.
[13:32]  <spot> and i'll send it to the list.
[13:32]  <rdieter> spot: thx, you're a saint.
[13:32]  <f13> I seriously don't understand what's so difficult about changing a couple packages to grow a BR on -static.
[13:32]  <spot> f13: i'll come talk to you
[13:32]  <hansg> Rathann, you don't know which packages are linked against libSDLmain.a
[13:33]  <Rathann> hansg: exactly
[13:33]  <spot> ok guys, we're done for the day.
[13:33]  <spot> thanks all.
[13:33]  <Rathann> hence it shouldn't be in -devel
[13:33]  <Kevin_Kofler> Easy: they failed to rebuild in the GCC 4.3 mass rebuild. ;-)
[13:33]  <caillon> f13, fwiw, many maintainers don't notice that their package failed rebuild.  i doubt they'd notice a static lib changed and needs rebuild either.  not that it's an argument one way or another.
[13:33]  <hansg> Rathann, I see your point
[13:33]  <abadger1999> We could set the virtual provide to  SDLmain-static instead of SDL-static but then we should also have a virtual provide for SDLmain-devel.... which is basically a subpackage
[13:33]  <Rathann> yeah, let's continue this in the mailing list
[13:34]  <f13> caillon: sometimes it's not about the packagers noticing, but about the security team seeking out and fixing things.
[13:34]  <Rathann> Kevin_Kofler: that's only because libSDLmain was moved to -static, isn't it?
[13:34]  <caillon> fair enough
[13:35]  <Rathann> hansg: and with BR: SDL-SDLmain-static (or something similar), you can track those packages
[13:35]  <hansg> bye all (baby is becoming heavy)
[13:35]  <Rathann> :)
[13:35]  <-- hansg has left this server ("Leaving").
[13:35]  <Rathann> ok, thanks everyone, see you
[13:36]  <abadger1999> Later
[13:36]  <-- Rathann has left this channel ("Leaving.").
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20080408&oldid=66593"