14:59:07 <spot> #startmeeting Fedora Packaging Committee
14:59:07 <zodbot> Meeting started Wed Dec  7 14:59:07 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:59:11 <spot> #meetingname fpc
14:59:11 <zodbot> The meeting name has been set to 'fpc'
14:59:14 <spot> #topic Roll Call
15:00:21 <spot> abadger1999, geppetto, racor, limburgher, rdieter, SmootherFrOgZ, tibbs|h: ping
15:01:24 * limburgher here
15:01:57 * racor here
15:02:02 * geppetto is here
15:02:07 <rdieter> here
15:02:33 * SmootherFrOgZ here
15:03:09 <tibbs|h> Howdy.
15:03:13 <spot> okay, thats 7 of us.
15:03:31 <spot> I'd like to reopen ticket #118
15:03:40 <spot> #topic Review /usrmove feature - https://fedorahosted.org/fpc/ticket/118
15:03:52 <spot> After our last meeting, panu posted some comments to that ticket
15:04:07 <spot> specifically, he pointed out that no scriptlet can fail and stop a full transaction
15:04:31 <tibbs|h> So I'm confused.
15:04:37 <spot> what that means is that any user who does a yum upgrade from f16 to f17 with /usrmove enabled will really destroy their system.
15:04:44 <tibbs|h> Because I said as much, and was contradicted.
15:05:14 <spot> tibbs|h: looks like you were right. i'm inclined to trust the rpm maintainer.
15:05:23 <tibbs|h> Indeed, I'd trust Panu.
15:05:30 <tibbs|h> But haraldh indicated that it was actually tested.
15:05:43 <limburgher> So this means a yum update will require a script to be run first?
15:05:50 <tibbs|h> In any case, it looks like we have no easy way out of this.
15:05:59 <spot> limburgher: yes, or else it will render the system quite likely unusable.
15:06:21 <geppetto> tibbs|h: Which is?
15:06:27 <limburgher> <exhale slowly>
15:06:32 <geppetto> tibbs|h: Oh … _no_ easy way out
15:06:42 * geppetto missed the no there :)
15:06:51 <tibbs|h> Well, the easy way out would be to backpedal on all of this.
15:06:54 <spot> based on that data, i would like to propose that we ask FESCo to reconsider /usrmove, specifically, because yum upgrades will not only not work, but have a strong chance of destroying the running system.
15:06:56 <limburgher> Reminds me of Python. . .Ypres: 1914. . .
15:07:16 <geppetto> spot: I'm happy to +1 that
15:07:31 <spot> +1 from me
15:07:43 <limburgher> spot: +eleventybillion
15:07:47 <tibbs|h> At this point I have to agree.
15:07:50 <tibbs|h> +1
15:08:07 <tibbs|h> At least until we get full documentation of what happens when upgrade scripts and such don't get run.
15:08:16 <tibbs|h> Maybe there's another way out that nobody has thought of yet.
15:08:36 <spot> tibbs|h: panu seemed to think the only way to prevent system destruction would be to hack stuff into the core of rpmlib
15:08:50 <spot> which he was noticably not at all happy about doing
15:09:12 <limburgher> Go figure.  Massive FS layout change and rpmlib update in one release?  Wheeee!
15:09:36 <geppetto> I will note that there have been bugs opened today, Eg. : https://bugzilla.redhat.com/show_bug.cgi?id=760996
15:09:50 <spot> limburgher: less of "rpmlib update" and more "disgusting hack inside rpmlib"
15:09:52 <tibbs|h> Oh, just wonderful.
15:10:26 <limburgher> spot:  I'm sorry, it's pronounced "disgusting hack", but spelt "update".
15:10:43 <spot> yeah. i think that is the hack that panu was talking about.
15:11:27 <tibbs|h> Fundamentally I don't have much of a problem with one-time disgusting hacks _if_ we're not screwing users in the process.
15:11:43 <mjg59> Before bouncing it back to fesco, can you discuss it with the feature owner?
15:11:54 <tibbs|h> In the past he's been here.
15:12:09 <tibbs|h> But not today, it seems.
15:12:09 <limburgher> tibbs|h: Which is why IMHO a script would have been better than an rpmlib hack, but still.
15:12:33 <mjg59> Because the packaging aspects of it aren't really fesco's pervue. We decided it was a worthwhile feature - actually making it happen is up to the feature owner, and the feature owner has to make that work in a way that's compatible with packaging
15:12:38 <spot> mjg59: the feature owner has basically said "hey, it all works, i've tested it."
15:12:44 <haraldh> hey
15:12:57 <spot> mjg59: which clearly doesn't map up with rpm's maintainer saying that there is no way it could work as he described
15:13:23 <limburgher> spot: Details.
15:13:29 <spot> haraldh: this thing is giving us massive heartburn.
15:13:31 <mjg59> spot: That's a discussion that has to happen, but it's not something that should be pushed back to fesco unless it's clear that they can't figure out why they disagree
15:13:41 <spot> haraldh: are you sure you really want to do this?
15:13:46 <haraldh> yes
15:14:48 <haraldh> there is no possibility to get "yum" do what we want
15:14:51 <spot> okay, since there is a patch to rpm that might prevent a yum upgrade from being destructive to the running system
15:15:02 <haraldh> the rpmlib patch is simple enough and the best guard
15:15:13 <spot> i propose that we hold the guideline change on panu accepting the fix (and or signing off on some other fix)
15:15:14 <tibbs|h> Any changes to rpm are going to have to be gated through Panu.
15:15:46 <haraldh> to quote Panu on #rpm: <Panu> harald: ok, I dont have any particular objections with the last version
15:15:52 <rdieter> spot: yup, +1
15:16:49 <tibbs|h> If Panu agrees with the proposed changes _and_ it actually works, great.
15:17:15 <haraldh> works, yes
15:17:15 <kay> it all works fine here
15:17:41 <tibbs|h> I'm tending to skepticism because the last thing that was supposedly tested.... wasn't.
15:17:42 <spot> haraldh: we're a bit more skeptical this week, because last week, you told us you'd tested yum upgrades and that worked.
15:17:57 <haraldh> spot, yes it did
15:18:03 <limburgher> How?
15:18:08 <haraldh> but
15:18:10 <tibbs|h> And we have Panu saying that it can't work.
15:18:16 <spot> "<haraldh> there is no possibility to get "yum" do what we want"
15:18:25 <spot> that would seem to conflict.
15:18:39 <kay> means we can ot get yum to do the actual conversion of the filesystem
15:18:47 <kay> but yum surely does the updates
15:18:48 <haraldh> but I didn't take into account, that other pre scripts could run
15:18:53 <spot> kay: yes, but we knew that wasn't possible last week.
15:19:13 <spot> haraldh: not just that, the rest of the transaction would complete.
15:19:29 <haraldh> which is now resolved
15:19:37 <spot> haraldh: only if panu takes that patch.
15:19:43 <haraldh> yes
15:20:13 * spot also put a comment in that bug about a detail of that patch which seems to be trying to slide the /usr/bin & /usr/sbin merge back into things
15:20:25 <haraldh> no, it does not :)
15:20:47 <haraldh> we just don't want to patch rpm very often
15:21:05 <spot> haraldh: imho, it is very unlikely that we would ever see that specific change occur
15:21:09 <kay> spot: that's just evaluated flag, for possible future use, not a plan, and not used today
15:21:21 <spot> so i would really prefer not to have stuff in rpmlib that implies that we will.
15:21:28 <kay> but they should be on the systems when we need to backport all that anyway
15:22:40 <tibbs|h> Where does this updated RPM need to be so that updates work?  Already on the system to be updated?
15:22:47 <spot> tibbs|h: yes.
15:22:51 <tibbs|h> Ugh.
15:23:05 <tibbs|h> So install F15 from media, update to F17 fails?
15:23:06 <spot> but i suppose filesystem could Require: rpm > NNN
15:23:26 <kay> tibbs|h: it will be an update to f17, f16, f15 and rhel
15:23:44 <spot> that would at least put the fixed rpm before it in the transaction, although, i'm not sure if rpmlib will take effect immediately or not
15:23:56 <spot> if i had to guess, i'd say it wouldn't
15:24:01 <spot> but panu would know for sure
15:24:11 <kay> spot: it does, you can not install a new filesystem.rpm
15:24:13 <tibbs|h> kay: An update doesn't help, because the system might not be updated when the upgrade starts.
15:24:32 <tibbs|h> But if pulling it in in the same transaction works, then great.  Another thing to test.
15:25:18 <geppetto> tibbs|h: No, it's like all rpmlib additions … you have to "pre-upgrade" rpm
15:25:30 <spot> So, i propose that we hold on this guideline change until Panu signs off on a solution to ensure that yum upgrades do not put the system at risk.
15:25:41 <geppetto> On the upside, we do have UI in yum which will tell the user WTF is going on.
15:27:05 <spot> i'm still not convinced that this solves the issue, to be honest, and i'm even less convinced that this feature is worth this heartburn.
15:27:39 <limburgher> spot:  I'm still waiting to be sold on the sexy new future this enables, that makes me eagerly want this change.
15:28:11 <haraldh> 1. if you want to do the dracut usrmove convert script, you will have to have a new dracut installed
15:28:18 <tibbs|h> It's not really our place to be sold.
15:28:25 <haraldh> 2. this dracut version can Conflict with the old rpm
15:28:34 <tibbs|h> They sold it to FESCo; we just figure out how to make it not screw people.
15:28:36 <haraldh> so, the upgrad path looks like this:
15:28:47 <haraldh> 1. upgrade dracut, which will require the new rpm
15:28:58 <haraldh> 2. reboot with the kernel command line parameter
15:29:05 <haraldh> 3. yum update
15:29:09 <spot> haraldh: yes, but if they just do: yum update
15:29:16 <spot> it will pull in dracut, rpm, and everything else.
15:29:21 <spot> and we have the same problem as before.
15:29:38 <haraldh> yes, but the rpm on the host system does not provide what filesystem needs
15:29:41 <spot> we can't force it to stop in the middle
15:29:44 <haraldh> so, no transaction at all
15:29:54 <spot> haraldh: the transaction is already going
15:29:57 <haraldh> no
15:30:05 <haraldh> because the deps are not fullfilled
15:30:11 <haraldh> for filesystem
15:30:19 <haraldh> it's a runtime dep
15:30:25 <spot> haraldh: the rpm on the host system doesn't know how to check
15:30:28 <spot> only the new one does
15:30:30 <haraldh> it's _not_ hardcoded in the rpm.rpm
15:30:46 <haraldh> it's generated at runtime of the new rpm
15:31:08 <spot> since we can't assume the system has the code to do the magic provides in rpmlib via your patch
15:31:09 <wwoods> (for the record, RPM transactions *can* be split - see split media)
15:31:59 <geppetto> wwoods: 1) Yeh, split media works so well. 2) You'd need to split the transactions _and_ perform the second one with the newly installed rpm
15:32:18 <spot> wwoods: been a long time since i looked at that, but iirc, it isn't really split, its just halting waiting for the disk storage to appear where the packages are that have been computed in advance.
15:32:28 <haraldh> also, if you use F17 live CD and F17 DVD install media, they already have the new rpm
15:32:43 <spot> haraldh: we're talking about yum update from f16 to f17
15:32:44 <wwoods> split media was terrible, sure, but that's more a problem of media handling.
15:33:01 <spot> and we cannot assume or force that the fixed rpmlib is present on the f16 system
15:33:04 <limburgher> tibbs|h: Agreed. :)
15:33:12 <spot> even if we push it as an update and beg people to update rpm first.
15:33:44 <spot> not without some sort of yum hackery that refuses to install an f17 package unless rpm is at a certain level.
15:33:51 <geppetto> Personally I think I'd actually prefer to not have it as an update … and just tell people that usrmove is incompatible with yum upgrades
15:34:07 <haraldh> spot, you will have to update dracut on F16 anyway first, to do the conversion
15:34:18 <geppetto> spot: the rpmlib deps. will do that, after they are downloaded and rpm checks them.
15:34:20 <spot> geppetto: but i don't want yum upgrade to destroy a system. there is a difference between "this doesn't work" and "this eats your OS"
15:34:21 <limburgher> geppetto:  I'd consider that failure.
15:34:31 <haraldh> spot, not possible
15:34:41 <spot> haraldh: panu seemed to think it was.
15:34:56 <geppetto> limburgher: *shrug* … I really don't see the difference between that and "it kind of works, you just have to do these 5 magical things correctly"
15:34:56 <limburgher> What if we take the slow approach, and update rpm to support this in f17, and do usrmove in f18?  We only support upgrades of any type for one release at a time anyway.
15:35:02 <kay> spot: but we don't do the conversion in the pretrans anymore
15:35:09 <kay> spot: that was panu's concern
15:35:17 <haraldh> libacl conflicts filesystem < 3 ... filesystem-3 needs the new rpmlib runtime generated deps
15:35:19 <kay> spot: we moved that stuff to rpm code now
15:35:20 <limburgher> geppetto:  My daughter would when her machine got eaten. :)
15:35:25 <spot> limburgher: that would work.
15:35:51 <haraldh> rpmlib runtime generated deps are only provided by _running_ a new rpm
15:35:59 <geppetto> Ok … AIUI with the patch they have … running the upgrade on a current rpm from F15/F16 will _fail_ … because the rpm doesn't know about the rpmlib dep.
15:36:05 <spot> geppetto: yes.
15:36:21 <tibbs|h> haraldh: That's kind of what I as thinking.
15:36:34 <geppetto> So there should be no eating of systems … you will be told no when rpm does it's dep. checking.
15:36:42 <spot> geppetto: okay.
15:36:53 <kay> people who want live upgrades need to convert the fs with dracut anyway, so i don't really see the problem here
15:37:02 <tibbs|h> So let's see if Panu will accept this.
15:37:12 <kay> there should be no case where we eat a system
15:37:13 <spot> tibbs|h: seems like the path forward.
15:37:13 <geppetto> It'll annoy users, because they'll have to download all the packages to find that out … but that's life.
15:37:25 <spot> geppetto: yeah, i don't like that users are left in the dark there.
15:37:27 <tibbs|h> And then if so, and it gets in and pushed out, then we can look at all of the testing and finally move on.
15:38:02 <haraldh> tibbs|h, right
15:38:28 <spot> +1 to tibbs's proposal
15:39:17 <haraldh> oh, and yum already gives the output, that you need a new rpm :)
15:40:22 * spot notes that we need some more votes here to reinstate a hold
15:40:43 <tibbs|h> You obviously have my +1.
15:40:57 <geppetto> sure, +1
15:41:11 <limburgher> +1
15:41:42 <SmootherFrOgZ> +1
15:42:13 <spot> okay, thats +5
15:42:31 <spot> #action This is placed on hold again, pending Panu's acceptance of a code change to rpmlib to prevent yum updates from succeeding unless rpm is upgraded and the filesystem is migrated via dracut. (+1:5, 0:0, -1:0)
15:42:33 <haraldh> and honestly, I like the rpm solution more than any %pretrans
15:42:55 <haraldh> much cleaner now
15:43:04 <tibbs|h> If Panu will take it.
15:43:22 <haraldh> yes
15:43:30 <spot> #topic Eclipse Packaging Guidelines Change - https://fedorahosted.org/fpc/ticket/122
15:44:53 <spot> So, the only thing that concerns me about this set of changes is the magic scriptlets
15:45:01 <spot> https://fedoraproject.org/wiki/User:Swagiaal/NewEclipsePackagingGuidelines#Running_the_Reconciler
15:45:21 <spot> a few reasons:
15:45:34 <spot> 1) it assumes there is no %post for the package already
15:45:47 <spot> 2) it assumes there is no %postun for the package already
15:45:58 <spot> 3) it assumes there is no %posttrans for the package already
15:46:02 <spot> 4) it uses %posttrans
15:46:22 <spot> 5) it's calling a shell script I can't see, without using pathing
15:46:51 <rdieter> whats wrong with %posttrans ?
15:47:06 <spot> rdieter: nothing, if it all works. :)
15:47:35 <tibbs|h> Yeah, not really pleased with macros that define entire sections.
15:47:37 * spot is not on an optimistic kick today.
15:47:46 <geppetto> There whole thing seems like a hack to do what font/desktop-files/etc. all want to do via. collections.
15:47:53 <rdieter> tibbs|h: oh, I missed that
15:48:03 <spot> i think i'd much rather see the eclipse template updated to include those scriptlets
15:48:16 <spot> add pathing to the .sh script
15:48:24 <geppetto> I'm also not sure why it'd need to run the script from postun on remove and again in posttrans
15:48:26 <spot> let us see a copy of that .sh script
15:48:30 <rdieter> spot: ah, totally agree
15:48:34 <tibbs|h> The %_eclipse_pkg macro expands to %post, %postun, and %posttrans.
15:49:31 <rdieter> I suppose it's not terrible to to provide %_eclipse_pkg for convenience I guess, for packages that don't have or need other scriptlets (as spot mentioned), but meh
15:50:16 <spot> so i propose we ask them to not do that supermacro, add pathing to the script, and show us a copy of the script so we can sanity check it (and see if we need to ignore failure cases)
15:50:38 <rdieter> ok, +1
15:51:03 <geppetto> Sure … we can suggest they do %_eclipse_pkg_postun etc.
15:51:25 <limburgher> +1
15:51:29 <geppetto> +1
15:51:31 <spot> geppetto: i have no problem with that (assuming it just gets added below %postun)
15:51:39 <geppetto> yeh, that's what I meant :)
15:51:51 <spot> we're at +4.
15:52:05 <tibbs|h> +1
15:52:06 <SmootherFrOgZ> +1 from me
15:52:28 <tibbs|h> Also, anyone think it's dumb to say "As of Fedora 9" in various places in that document?
15:52:56 <spot> tibbs|h: eh. its a minor thing on the grand scale of things.
15:53:12 <tibbs|h> Oh, sure, but as long as we're in the document...
15:53:17 <rdieter> As of when fire was discoverred...
15:53:33 <spot> #action Send back to author for changes (details will go in ticket) (+1:6, 0:0, -1:0)
15:54:55 <spot> while i'm writing that up in the ticket, look at 123, it should be a no brainer
15:54:58 <spot> i almost just did it
15:55:04 <spot> but i figured we could review it
15:55:08 <spot> #topic https://fedorahosted.org/fpc/ticket/123
15:55:11 <tibbs|h> I would also like to know that others in the Eclipse/Java community are on board with those Eclipse changes.
15:55:21 <spot> tibbs|h: overholt is, at a minimum
15:55:29 <rdieter> 123 , yeah, just do it, +1
15:55:31 <tibbs|h> I saw he was CC'd.
15:55:37 <tibbs|h> 123 is just do it, certainly.
15:55:49 <limburgher> Oh.  Yeah.  Absoltively.
15:56:18 <geppetto> yeh, +1
15:56:48 <geppetto> ha … fair enough that scriptlet is identical to the eclipse thing
15:57:09 <geppetto> Well, almost
15:59:40 <spot> can we get a quick vote on 123?
15:59:44 <spot> +1
15:59:48 <rdieter> +1
15:59:52 <SmootherFrOgZ> +1
16:00:07 <geppetto> +1, again
16:00:08 <tibbs|h> +1
16:00:27 <spot> #action Approved, easyfix (+1:5, 0:0, -1:0)
16:00:40 <spot> #topic WhenIsGood
16:00:50 <spot> you all should have gotten an email about the whenisgood
16:00:55 <spot> please go do it if you haven't done so
16:01:09 <spot> i'll send out an email with the results when i get a majority of responses
16:01:30 <geppetto> Is it possible to see results before then?
16:01:55 <spot> geppetto: umm, yeah, as soon as i fix tomboy to open again and show me the magic results code, i will send it to you
16:02:04 <spot> (yay, rawhide mono)
16:02:31 <geppetto> Look in the text files in ~/.tomboy ?:)
16:02:41 <spot> geppetto: yeah, that will work too.
16:03:01 <spot> okay, i have to go off to another meeting now
16:03:06 <spot> so i'm going to end this one, thanks all
16:03:09 <spot> #endmeeting