Packaging:Minutes20080520

Fedora Packaging Committee Meeting of {2008-05-20}

Present

• DenisLeroy (delero)
• DominikMierzejewski (Rathann)
• 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:

• Recording the upstream status of patches

http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamStatus

• Mandatory verification of desktop files

http://fedoraproject.org/wiki/PackagingDrafts/DesktopVerify

Votes

The following proposals were considered:

• Withdrawing the JPackage naming exception
• The current exception allowing "jpp" in release strings is at http://fedoraproject.org/wiki/Packaging/JPackagePolicy
• Accepted (7 - 0)
• Voting for: spot delero Rathann abadger1999 rdieter racor tibbs (all committee members present voted for)

Other Discussions

• A draft is being worked up regarding the use of alternatives.

If you are experienced with the use of alternatives and would like to give input on the issues surrounding alternatives and packaging, please join us on the fedora-packaging mailing list.

IRC Logs

[12:01]  * spot is here, one sec
[12:02]  <spot> aaanyways.
[12:02]  <spot> who else is around for FPC
[12:03]  * delero here
[12:03]  * tibbs here
[12:05]  <rdieter> here
[12:05]  <racor> here
[12:05]  <spot> abadger1999, racor?
[12:06]  * spot looks for the others
[12:06]  <abadger1999> here
[12:06]  <spot> Rathann said he was going to miss it
[12:07]  <spot> i don't know where Xavier or Hans are.
[12:07]  <spot> ok, first item on the agenda
[12:07]  <spot> (get your fire proof vest on...)
[12:07]  <spot> Removing the JPackage naming exception.
[12:08]  * dbhole_ tests his flamethrower
[12:08]  <spot> I posit that three viable alternatives to using the "jpp" repotag in Fedora packages have been identified.
[12:08]  <spot> 1. A yum group exclude plugin
[12:08]  <spot> 2. The yum-priorities plugin
[12:08]  <spot> 3. Provides, as documented by f13 on the Jpackage mailing list
[12:09]  <spot> Thus, the terms of the exception have been met. There exist functional workarounds for the technical issues that merited the exception.
[12:09]  <spot> I propose that we vote to lift the exception.
[12:09]  <tibbs> So, I've a question.
[12:10]  <overholt> I think you're causing work for JPackage (unnecessarily IMO) with this
[12:10]  <dbhole_> #1 cannot be used because it will require jpackage to change their packages as well, to set the same group
[12:10]  <overholt> and it doesn't help with the perception that Fedora has no concern for stuff outside Fedora
[12:10]  <tibbs> Were the requirements in the document we were given the only requirements?
[12:10]  <spot> dbhole_: and yet, #1 is what was asked for.
[12:10]  --> Rathann has joined this channel (n=rathann@235-goc-28.acn.waw.pl).
[12:10]  <overholt> it makes us all look like self-centred jerks
[12:10]  <Rathann> o/ present
[12:11]  <tibbs> It sounds like there are other requirement we weren't told about.
[12:11]  <Rathann> sorry for being late
[12:11]  <racor> AFAIU, neither #1 nor #2 work on the rpm-level => these are non-options, IMO
[12:11]  <overholt> tibbs, well, there was the months-long thread about it back in the day
[12:11]  <spot> this is an issue of ensuring clean rpm ordering in Fedora.
[12:11]  <delero> racor: why is a yum-level solution not good enough ?
[12:11]  <dbhole_> spot: Not it was not. What was asked for was something we can do, and only WE have to do, that allow us to meet all the requirements that caused the exception in the first place. It is hardly right to be telling jpackage to alter 500+ packages because *we* want it
[12:11]  <overholt> clean rpm ordering was ensured with the scheme, was it not?
[12:11]  <racor> rpm -U / -i MUST work
[12:11]  <spot> dbhole_: again, no one is asking Jpackage to do anything.
[12:11]  <tibbs> I could care less about that.  We asked for the full list of requirements, we got a list, and now it seems that we can't make a decision based on that list.
[12:12]  <spot> I feel that we've met the terms of the exception to our naming guidelines
[12:12]  <spot> possibly even gone above and beyond what is required.
[12:12]  <abadger1999> dbhole_: If JPackage has to change their groups, then the list of technical requirements we were given is not complete.
[12:13]  <overholt> or the solution didn't take them into account
[12:13]  <overholt> hence my earlier point
[12:13]  <spot> this is no different from importing packages from any other repo which conflict with the Fedora Guidelines
[12:13]  <spot> the naming guidelines exist for a specific reason, to ensure clean rpm transactions with n-v-r ordering
[12:14]  <overholt> which you fixed with the scheme
[12:14]  <overholt> *you* came up with
[12:14]  <spot> overholt: as a temporary workaround
[12:14]  <spot> it was always intended to be temporary until better workarounds were found
[12:14]  <overholt> spot, fine, but your new 'solution' screws people over outside of Fedora
[12:14]  <spot> better workarounds have been found
[12:14]  <tibbs> Honestly, is Fedora allowed to choose its own packaging rules?
[12:14]  <overholt> better in some people's eyes
[12:14]  <rdieter> "... to ensure clean rpm transactions" what if that's not valid?
[12:15]  <spot> overholt: it doesn't screw anyone to remove three characters.
[12:15]  <overholt> I really don't care about "jpp" itself
[12:15]  <abadger1999> overholt: Tell us what the new requirement is that screws people over.
[12:15]  <overholt> I'm mostly annoyed with the way this has been rammed through
[12:15]  <rdieter> rpmdev-vercmp 0 1 2 0 1 2jpp  says: 0:1-2jpp is newer  , isn't that what we want?
[12:15]  <dbhole_> spot: And how is #1 supposed to address pre existing packages? If I installed the java stack on my system at install time and wish to move away later, it would not work (atleast I don't see how it could)
[12:15]  <abadger1999> If we don't know the requirements we can't address them.
[12:15]  <spot> rammed? this has been a YEAR in coming.
[12:15]  <overholt> abadger1999, Jpackage has no time to react and implement this
[12:15]  <tibbs> What the hell?  "Rammed"?}
[12:15]  <overholt> it has felt very much like a personal vendetta the whole time
[12:15]  <abadger1999> overholt: As far as I can see they don't have to implement anything.
[12:15]  * spot sighs
[12:15]  <abadger1999> overholt: That's the problem.
[12:15]  <spot> this is not a vendetta. let that go on the record.
[12:15]  <overholt> abadger1999, I read their mails as they do
[12:15]  <abadger1999> overholt: Tell us what the requirement is that they feel they have to implement for.
[12:15]  <spot> this is just about Fedora being internally consistent.
[12:15]  <overholt> I didn't say it was a vendetta
[12:16]  <overholt> I said it felt like a vendetta
[12:16]  <overholt> and if *feels* like we're unnecessarily forcing stuff on others
[12:16]  <overholt> it just feels wrong
[12:16]  <overholt> yes, cleanliness is nice
[12:16]  <overholt> and consistency
[12:16]  <spot> overholt: your feelings are noted.
[12:16]  <overholt> and necesssary, even
[12:16]  <tibbs> What stuff are we forcing on others?
[12:16]  <tibbs> Honestly, I don't see it.
[12:16]  <abadger1999> tibbs: +1.
[12:16]  <overholt> we're making it so that JPackage developers can't use Fedoora, aren't we?
[12:16]  <spot> overholt: not at all.
[12:16]  <rdieter> no
[12:16]  <abadger1999> overholt: Not that I can see....
[12:16]  <overholt> then I guess I read the thread wrong
[12:17]  <overholt> sorry
[12:17]  <abadger1999> And that's what you have to explain to us.
[12:17]  <tibbs> What, we have a user list and prevent them from logging in or something?
[12:17]  <overholt> haha
[12:17]  <abadger1999> If you can explain that then we'll know what's wrong with the change.
[12:17]  * overholt notes that he's not a JPackage developer
[12:17]  <spot> the only thing we're doing is not permitting Fedora packages to use "jpp" in their Release.
[12:17]  <abadger1999> If you can't then we'll vote on this.
[12:17]  <spot> that is it. 100%.
[12:17]  <overholt> I must have mis-interpreted the thread
[12:17]  <overholt> carry on
[12:18]  <spot> FPC members, are you ready to vote on this?
[12:18]  <-- overholt has left this channel ("Leaving").
[12:18]  <dbhole_> spot: of the options 1,2,3, 1 and 2 cannot deal with pre existing packages, so they are out
[12:18]  <abadger1999> I hate voting thinking that I'm missing something
[12:19]  <dbhole_> spot: And 3 is very much a hack
[12:19]  <abadger1999> but if no one explains the problem they think exists I think we have to.
[12:19]  <dbhole_> I would like to solve this _properly_ by allowing a decent grouping system in rpm
[12:19]  <spot> +1 to removing the exception.
[12:19]  <dbhole_> that is what was agreed on with the exception
[12:19]  --> fitzsim has joined this channel (n=fitzsim@209.167.232.100).
[12:19]  <dbhole_> that it will be removed when a solution is available
[12:19]  <dbhole_> imo a hack is not a solution
[12:19]  <delero> +1 to removing the exception also
[12:20]  <dbhole_> and I partially agree with what overholt said.. this is being rammed through for no reason
[12:20]  <dbhole_> no new technical reason has come up that necessites this, outside of some specific individuals wanting it removed
[12:20]  <spot> dbhole_: believe me when i say that i cannot ram anything through both FPC and FESCo.
[12:20]  <tibbs> "no reason"?
[12:20]  <abadger1999> dbhole_: 1) Define pre-existing package
[12:20]  <abadger1999> In JPackage or in Fedora
[12:21]  <tibbs> Why is it that the reasons we have stated amount to "no reason"?
[12:21]  <dbhole_> abadger1999: During installed, if the java stack is installed on the machine, the yum exclusion plugins will not be able to allow grouping of the "java packages"
[12:21]  <abadger1999> dbhole_: So what is a pre-existing package?
[12:22]  <dbhole_> tibbs: sorry, I should perhaps clarify. I understand that Fedora wants all packages to conform to a specific guideline. What I meant was that no new technical reason has come up since the exclusion was agreed upon
[12:22]  <tibbs> The exception was always intended to be temporary.
[12:23]  <abadger1999> dbhole_: The exclusion was forced upon us with the explicit statement that it is temporary until another method of doing it was found.
[12:23]  <Rathann> dbhole_: but the exclusion had a timeout, had it not?
[12:23]  <dbhole_> abadger1999: Well, say I am installing fedora, I select all packages to be installed, which includes a package, say "xalan-j2" which is a fedora/jpackage common package. The yum exclusion plugins proposed will not be able to mitigate this, as they can only exclude packages when new ones are being installed
[12:23]  <Rathann> dbhole_: so what's the problem in your case?
[12:24]  <delero> dbhole_: a repo priority plugin would solve this though woudln't it ?
[12:24]  <tibbs> I don't understand why you'd even install something that you don't want to be installed.
[12:24]  <dbhole_> Rathann: No, the excludes page states that it will be revisited when a proper solution is found. I don't think one has been. We are using (proposing) workarounds and hacks .. which would be fine if there was a new, technical reason to remove "jpp". But there is no new, technical reason to remove it that I can see
[12:25]  <Rathann> dbhole_: IMHO there was never a good reason to have it there
[12:25]  <spot> I think there are two flaws in how we originally handled the exception. We did not put a time limit on it, nor did we define clearly who would be able to define a proper solution.
[12:25]  <abadger1999> dbhole_: The use of the "jpp" tag is temporary. Once there is no longer a technical need as defined in this document, it will be removed from all Fedora packages.
[12:25]  <tibbs> I get the impression that if we accept this line of reasoning we'll simply never be "allowed" to decide on our own internally consistent packaging guidelines.
[12:25]  <dbhole_> tibbs: You are right, in most cases it would. What I am saying is that it limits options. If one were to install a java package at install time (for whatever reason), they are basically stuck
[12:25]  <spot> tibbs: i agree.
[12:26]  <delero> dbhole_: i don't agree there for solution 2
[12:26]  <spot> vote stands at +2 (+3 with Rathann's mail in vote)
[12:26]  <dbhole_> tibbs: not true. If rpm query options properly support grouping, the exception can be removed , and it would be the right solution
[12:26]  <Rathann> spot: I still vote +1 :)
[12:26]  <abadger1999> vote to remove +1
[12:26]  <rdieter> +1 to removing the exception
[12:27]  <tibbs> dbhole_: You say they're "basically stuck" but I really don't see how jpp in the name actually gets you unstuck.
[12:27]  <racor> +1 to removing the exception
[12:27]  <spot> tibbs, racor, we're at +5, but I would like your vote on the record, so no one accuses me of shenanigans.
[12:27]  <tibbs> I mean, you uninstall the package.
[12:27]  <tibbs> I really wanted to see some kind of agreement.
[12:27]  <dbhole_> tibbs: how is one supposed to know that is a jpp package, though?
[12:27]  --> couf has joined this channel (n=bart@fedora/couf).
[12:28]  <dbhole_> tibbs: currently, the release string is the only one that signifies the origin
[12:28]  <spot> dbhole_: its worth noting that it is a Fedora package.
[12:28]  <dbhole_> spot: We need interoperability with jpp. and the goodwill of that community. We simply don't have enough java packagers. I own 61, and with 30 new coming my way
[12:28]  <spot> tibbs: would you like to vote?
[12:29]  <dbhole_> 91 packages with 0 time alloted
[12:29]  --> overholt has joined this channel (n=overholt@209.167.232.100).
[12:29]  <tibbs> I just haven't seen anything which would convince me to vote any other way than to remove the naming exception.
[12:30]  <tibbs> I mean, if it all comes down to knowing which packages you need to uninstall when you want to replace a bunch of packages in the distro with other packages, then it seems pretty obvious.
[12:30]  <abadger1999> dbhole_: You need to tell us why we're sacrificing goodwill by making changes to the _Fedora_Packages_.
[12:30]  <overholt> I'd like to apologize for my comments earlier if they were rude or inappropriate.  I only meant to give my impression of things and not state fact.  FWIW, I think you all do a great job and this was a tough situation.  I apologize again.
[12:30]  <spot> overholt: no worries. this is an emotionally charged issue.
[12:30]  <tibbs> I really don't understand why the solution isn't "see which packages are in the jpackage repo, uninstall all of them".
[12:30]  * spot isn't entirely sure why... but still.
[12:30]  <overholt> spot, agreed (on both counts)
[12:30]  <dbhole_> abadger1999: There is no easy way to switch stacks. The current one works, and I am afraid that the new ones will not work as well under all circumstances that the current one works under
[12:31]  <abadger1999> overholt: No problem.  We're in a tough spot as people are yelling at us but none of the yelling has seemed to have a technical basis yet.
[12:31]  <tibbs> Anyway, I'll vote +1 for removing the exception.
[12:31]  <overholt> abadger1999, yeah, it's hard.
[12:31]  * rdieter thinks f13's proposed solution has the most promise.
[12:31]  <spot> ok, all votes are on the record. We'll pass this hot potato to FESCo for ratification.
[12:31]  <delero> i prefer a solution at the yum-level personally
[12:31]  * abadger1999 likes repo priorities.
[12:32]  <delero> since this is fundemantally a repo management issue
[12:32]  <Rathann> exactly so
[12:32]  <spot> believe it or not, this is the only item on today's agenda.
[12:32]  <spot> the floor is now open for any other issues that are not the jpp naming exception.
[12:32]  <abadger1999> dbhole_: The current one does not work.  I pointed that out in one of my emails but no one addressed it.
[12:33]  <dbhole_> abadger1999: What cases does it fail under? (sorry, I must have missed it.. that thread is rather long :/)
[12:33]  * Rathann would like to excuse himself and tend to other pressing issues
[12:33]  * overholt leaves with a red face and his tail between his legs for being a jerk.  sorry for being so hot-headed.
[12:33]  <-- overholt has left this channel ("Leaving").
[12:34]  <Rathann> thanks and bye
[12:34]  <-- Rathann has left this channel ("Leaving.").
[12:34]  <tibbs> Actually, I really don't get how having jpp in all of the release strings actually helps you at all.  If the fedora packages had "notjpp" in them then you'd actually be able to tell the java packages you have installed that didn't come from jpp.
[12:34]  <tibbs> Fortunately nobody's proposed that.
[12:35]  <dbhole_> tibbs: because the current way worked until now, there was never a need
[12:35]  <dbhole_> and it still works
[12:35]  <tibbs> For some definition of "works" which has yet to be explained by anyone in a way that allows me to understand it.
[12:36]  <spot> ok, i'm not hearing any other topics.
[12:36]  <abadger1999> I want to replace all Fedora java packages on my system with JPackage.  I can't tell which packages are from Fedora and which are from JPackage because they both have *jpp* in the release tag.
[12:36]  <tibbs> spot: Well, the alternatives thing was interesting.
[12:36]  <tibbs> I don't really know what the proper answer is there.
[12:36]  <spot> tibbs: indeed, but the draft is not ready for that yet.
[12:36]  <spot> Rathann is working on a draft
[12:36]  <delero> is there a tool that manages the alternatives sym links ?
[12:36]  <delero> i.e. is the /etc/alternative symlink only set by rpm ?
[12:37]  <spot> delero: alternatives does it for you.
[12:37]  <delero> spot: ah ok thx
[12:37]  <spot> /usr/sbin/alternatives
[12:37]  <rdieter> man alternatives
[12:37]  <dbhole_> abadger1999: right, but you can remove *jpp* easily enough, and then yum install from a specific repo, with an excludes *jpp* in the yum conf for the other repo
[12:37]  * delero wonders about /etc/alternatives/gcc
[12:37]  <spot> delero: eeeek.
[12:37]  <racor> delero: whatfor?
[12:37]  <delero> we have 3 packages trying to override that right now
[12:38]  <delero> distcc, cccache and icecream
[12:38]  <dbhole_> spot: so which of the 3 solutions will be proposed to address the issue?
[12:39]  <spot> dbhole_: honestly, thats up to the Fedora Java packagers.
[12:39]  <tibbs> Jeez, just query the "specific repo", remove any packages from the system that exist there, and then install the ones you want.
[12:39]  <tibbs> Sure, you remove too much, but removing anything with jpp in the name does the same thing.
[12:40]  <tibbs> Was this whole thing really over something so amazingly trivial?
[12:40]  <abadger1999> dbhole_: So... that doesn't change and, in fact becomes less hacky.  Remove all java packages and then yum install with specific repo tagged with repo priorities.
[12:41]  <rdieter> tibbs: +1, and a miracle the exemption lasted this long
[12:42]  <dbhole_> tibbs: hmm, of all the things.. I cannot believe your solution was not proposed on that huge thread :/
[12:43]  <tibbs> Now, I can't promise that the tools make it quite that easy, but if not then they can be trivially made to do so.
[12:44]  <abadger1999> Re: alternatives.  If multiple packages %ghost the symlinks will they be removed when one of the packages is removed?
[12:44]  <tibbs> Don't you have to call alternatives in %postun in that case?
[12:44]  <abadger1999> It seems like it shouldn't but I don't know if %ghosts are special.
[12:45]  <tibbs> Admittedly I know little about how users and packagers are actually supposed to call alternatives.
[12:45]  * abadger1999 is of the opinion that alternatives should be used rarely as well.
[12:46]  <spot> alternatives hurts my brain pretty thoroughly
[12:46]  <tibbs> Rarely, sure, but you can't really escape it entirely.
[12:46]  <tibbs> There's no good way for distcc to replace gcc otherwise.
[12:46]  <tibbs> Well, $PATH, I guess.
[12:46]  <spot> tibbs: did FESCo ratify the two issues from last meeting?
[12:46]  <spot> i seem to recall they did, but i wanted to be sure.
[12:46]  <tibbs> Yes, as far as I can remember.
[12:47]  <tibbs> I would have sent any comments back to FPC.
[12:47]  <spot> mmkay.
[12:47]  <abadger1999> Unless we say that distcc shouldn't be replacing gcc...  Not sure if that's something we want to get into, though.
[12:47]  <tibbs> Well, we might consider getting into it one day, I guess.

[12:50]  <abadger1999> Okay, well, I've got nothing else for this week.
[12:51]  <delero> we can continue the alternatives discussino on the mailing list
[12:52]  <spot> thanks guys, meeting done.
[12:52]  <spot> i'm going to go stop drop and roll for a while
[12:54]  <-- delero has left this channel.
[12:57]  <rdieter> [12:44]  <abadger1999> Re: alternatives.  If multiple packages %ghost the symlinks will they be removed when one of the packages is removed? : answer: no, only when all owners are removed (just like any other multiply-owned file or directory)
[12:57]  <abadger1999> rdieter: Thanks!
(later)
[14:04]  <f13> dbhole_: you still around?
[14:04]  <f13> dbhole_: tibbs: that solution you proposed I thought was deemed unacceptable because it didn't work at the rpm level, only at the yum level.
[14:05]  <tibbs> The one I talked about doesn't have much to do with yum.
[14:06]  <tibbs> Obviously you have to have a source of rpms; from that you can make a list of the packages that might be on your system you need to remove.
[14:06]  <f13> <tibbs> Jeez, just query the "specific repo", remove any packages from the system that exist there, and then install the ones you want.
[14:06]  <tibbs> "query" could be ls|sed
[14:06]  <f13> ok, that 'query the specific repo' smacks of yum to me.  That's why I avoided anything of that nature in my proposals.
[14:06]  <f13> I was under the assumption that a hard requirement had to be that you could do this at the rpm level disconnected from the network
[14:06]  <tibbs> Besides, "specific repo" wasn't my wording; that's why I quoted it.
[14:06]  <f13> nod
[14:13]  <f13> I'll note that there still have been no relevant replies to my Provides: proposal on the jpackage discuss list :(