16:07:55 <spot> #startmeeting Fedora Packaging Committee
16:07:55 <zodbot> Meeting started Wed Jun  6 16:07:55 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:07:59 <spot> #meetingname fpc
16:07:59 <zodbot> The meeting name has been set to 'fpc'
16:08:06 <spot> #topic Roll Call
16:08:07 * geppetto is here.
16:08:10 * abadger1999 here
16:08:30 * Rathann here
16:08:56 <spot> rdieter, limburgher, SmootherFrOgZ: ping
16:10:19 <rdieter> hola
16:10:20 * limburgher here.
16:10:33 <spot> okay, thats 6 of us.
16:11:02 <spot> #topic Requesting a new exception for a /nix directory in the root hierarchy - https://fedorahosted.org/fpc/ticket/180
16:11:18 <spot> i note that there are two -1 votes already in the ticket for absent fpc members
16:11:36 <geppetto> My initial reaction was -1 too.
16:12:02 <limburgher> I knew I could make the meeting, so I withheld my -1 vote until now.
16:12:23 <spot> IMHO, Fedora needs another third party packaging mechanism like I need space herpes.
16:12:36 <geppetto> indeed.
16:12:41 <limburgher> spot: the gift that keeps on giving.
16:12:46 * hircus1 just arrived - went to the wrong meeting room, sorry
16:13:33 <limburgher> Why can't they just use cpeargempan like everyone else?
16:13:50 <abadger1999> limburgher: haha
16:14:20 <spot> i would think that even if the packages have hardcoded pathing of /nix/foo/bar, it should be possible to patch the tooling to check for nix, determine that it doesn't exist, and try /opt/nix
16:14:36 <hircus1> I can recommend that to upstream
16:14:37 * spot is intentionally ignoring the "merits" of "nix"
16:15:02 <abadger1999> And/Or a ~/nix directory
16:15:10 <spot> abadger1999: that's even better
16:15:10 <geppetto> Do we want Fedora packages stuffing things in /opt either?
16:15:12 <limburgher> We could fork it. . .and call it. . .
16:15:18 <hircus1> Unix? :)
16:15:35 <spot> So, i'm -1. I don't think this merits an FHS exception.
16:15:36 <hircus1> perhaps /var/lib/nix
16:15:38 <limburgher> geppetto:  No, but that's what upstream might want to do for their own purposes.
16:15:53 <limburgher> Ixnay.
16:15:59 <abadger1999> Yeah, -1 from me.
16:16:04 <limburgher> /usr/local/opt/lib/nix?
16:16:13 <geppetto> limburgher: Yeh, just thinking of something that they could use that we'd be happy with
16:16:24 <geppetto> Where does zeroinstall drop all it's stuff?
16:16:36 <hircus1> zeroinstall? ~/.cache/0install
16:16:45 <hircus1> there's an optional system-wide cache in /var/lib/0install
16:16:58 <spot> /usr/share/nix is probably the closest thing that we'd consider sensible, ignoring the fact that nix is container based and thus, that's a giant FHS violation in itself
16:16:59 <rdieter> so, the nix manual says if /nix isn't used, then "doing so makes it impossible to use pre-built binaries from the standard Nixpkgs channels — that is, all packages will need to be built from source."  not sure what the full implications of that is, but is that so bad?
16:17:02 <geppetto> yeh, so I'd tell nix to follow that.
16:17:19 <Rathann> -1 from me as well
16:17:24 <abadger1999> ButI dod see that there's parallels to the python-pip rubygem, etc stuff.  I don't think I'd object to it purely on an alternate-package-manager basis.
16:17:34 <hircus1> if there are many FHS-related issues, perhaps it's best to package it separately then -- if it won't get in even with the changes
16:17:36 <spot> rdieter: depending on what nix is written in, it should be about a 5 line code change to have it support an alternate home.
16:17:37 <limburgher> rdieter:  So it says it really can't follow FHS.
16:17:56 <spot> hircus1: the FHS related issues probably only apply to "nix packages"
16:18:02 <spot> hircus1: not the base tooling
16:18:07 <hircus1> spot: Perl - but the configure script does let you override the store location
16:18:12 <limburgher> abadger1999:  I don't either, I think there are bigger issues.
16:18:17 <hircus1> the problem is that you then need to rebuild the binary packages it provide
16:18:20 <spot> and i don't think we'd ever permit nix packaging in Fedora proper
16:18:48 <limburgher> Just like we wouldn't support packaging in dpkg.
16:18:50 <spot> hircus1: this is just an attempt to support the nix tooling, right, not a plan to add nix-format packages to Fedora?
16:19:08 <hircus1> spot: could you clarify the distinction between the two?
16:19:26 <geppetto> spot: Right, but like zeroinstall I assume what they want is that you can get the tools and then set them up to use their external repos. … and that doesn't work if we don't allow /nix.
16:19:31 <spot> hircus1: the nix tools allow you to install "nix-format" packages from third party sources
16:19:48 <hircus1> ah. I see. so use nix tools with our own repos, not the Nix-provided repos...
16:19:51 <spot> we're not interested in having these "nix-format" packages in Fedora at all, because they would violate the FHS
16:20:06 <spot> but i don't really care what an end-user chooses to do
16:20:27 <abadger1999> <nod>
16:20:29 <spot> so i'm not opposed to the nix tools, per se, just that their choice of top-level directory store is bad
16:20:40 <limburgher> And if nix-tools after installation connect to third-party repos, that's a showstopper.  Think rpmfusion.
16:21:02 <hircus1> limburgher: nix by default does not configure any repo, at least the way I'm packaging it, so we're safe there
16:21:05 <spot> and it shouldn't be hard for their tooling to note that a binary nix-format package assumes /nix, check for /nix, if not found, check for other "common locations"
16:21:20 <spot> then relocate upon install
16:21:30 <rdieter> so it comes down to whether we're willing to 'allow
16:21:35 <spot> (there may be some eccentricity I'm not aware of)
16:21:41 <rdieter> nix prebuilt packages to use /nix or not.  meh
16:21:57 <limburgher> hircus1: that's good.
16:21:57 <spot> alternately, you could include README.Fedora that says "if you want to use prebuilt packages, you need to manually create /nix"
16:22:21 <limburgher> spot:  Eww.  No, I'd rather change the path.
16:22:22 <hircus1> if the tool is patched to support two locations, yes.
16:22:22 <spot> under the "user did it, not my problem" rule.
16:22:36 <limburgher> spot:  They get to keep both pieces.
16:22:39 <hircus1> or do what some RPM Fusion packages do and override+conflict with the Fedora package
16:23:02 <hircus1> seems reasonable - thanks.
16:23:02 <spot> limburgher: i can see where the nix-format might have literally hacked up rpath on the binaries/libs it builds
16:23:18 <spot> limburgher: thus, a simple relocation would just cause things to break
16:23:18 <hircus1> it does
16:23:23 <limburgher> spot:  Good times.
16:23:40 <spot> hircus1: yeah, so in that case, i think your choices are "don
16:23:42 <hircus1> because you basically hardcode the full path (in the store) of the specific version of the library you build against
16:24:19 <spot> choices: don't package at all, put in rpmfusion, put in fedora without /nix and include docs about how to enable third-party support.
16:24:28 <abadger1999> export NIXDIR=/opt/nix ; nix => if $NIXDIR:  $OTHERDIR=$NIXDIR + $OTHERDIR
16:24:45 <hircus1> some FPC members are of the opinion that RPM Fusion would reject it on the same ground of FHS non-compliance
16:24:47 <spot> abadger1999: i don't think that will work without ELF magic
16:24:52 <rdieter> ok, nix is silly, but we either allow it to 'just work', or ... not.  I guess I prefer the former, don't see any ill side-effects personally.  consider me +1 in favor of the exception
16:24:55 <limburgher> Coming from the other angle:  I'm a user.  What does using nix get me?
16:25:12 <abadger1999> LD_LIBRARY_PATH=$NIXDIR + $LIBDIR
16:25:13 <abadger1999> :-)
16:25:23 <Rathann> limburgher: you can use it to get a PhD ;)
16:25:25 <spot> rdieter: if they would just not have been stupid with their choice of toplevel directory, this wouldn't even be fpc worthy
16:25:26 <hircus1> you get to install packages without affecting other users
16:25:34 * limburgher throws object at abadger1999
16:25:50 <hircus1> Rathann: Eelco got a PhD writing NixOS already, I think
16:25:54 <rdieter> spot: true true
16:26:12 <spot> i don't want to open a door here to allow FHS violations just because you're lazy.
16:26:23 <spot> s/lazy/stupid
16:26:27 <Rathann> hircus1: my point was that that's all it's good for upon cursory reading of the docs
16:26:35 <limburgher> hircus1:  Then why a /nix that all users share?  Why not inside ~?
16:27:15 <hircus1> limburgher: to save space, I think? and also that the fixed-path trick to isolate packages' dependencies from each other probably wouldn't work if everything is within user directories
16:27:48 <hircus1> anyway, wouldn't want to hog all the time on this ticket -- unless this is the only topic
16:27:50 <abadger1999> limburgher: rpath and pre-built binaries probably wouldn't work with that either
16:28:24 <spot> i don't see more than a single +1 here
16:28:31 <limburgher> hircus1, abadger1999:  Then I'm missing how using /nix keeps from affecting other users, esp. if they's also using nix.
16:28:49 <limburgher> Anyway. . .
16:28:57 <Rathann> limburgher: the docs say it does it "securely"
16:28:58 <limburgher> spot:  Yeah, looks rejected.
16:29:00 <spot> limburgher: i think the tooling is making user specific components in /nix behind the scenes
16:29:10 <spot> and then symlinking
16:29:18 <spot> but thats just a guess
16:29:18 <hircus1> limburgher: ah. when you use Nix on other operating systems, you get a symlinked tree in ~/.nix-profile
16:29:19 <limburgher> spot, Rathann:  . . . .oh.
16:29:27 <hircus1> just like when you use stow. that's how it works..
16:29:47 <Rathann> When a unprivileged user runs a Nix command, actions that operate on the Nix store (such as builds) are forwarded to a Nix daemon running under the owner of the Nix store/database that performs the operation.
16:29:54 <Rathann> quoting the docs
16:30:04 <hircus1> in full NixOS, the normal system hierarchy is also basically symlinks -- versioned, so you can switch between different install profiles and delete the ones you don't want
16:30:32 <limburgher> hircus1:  And if we have, say, the system firefox (12), a nix Firefox for Alice (11), can Bob have a nix Firefox (10) that won't mess up things for Alice?
16:30:37 <spot> #action FHS violation rejected, please ask Nix upstream to reconsider their choice of toplevel home to something FHS compliant (e.g. /usr/share/nix).
16:30:39 <hircus1> limburgher: yes
16:30:41 <abadger1999> Rathann: It's Ximian RedCarpet!
16:30:48 <abadger1999> :-)
16:30:58 <hircus1> spot: clarification - would /var/lib/nix do as well?
16:31:03 <spot> hircus1: yeah.
16:31:07 <hircus1> because I take it you don't want binaries and libs in /usr/share
16:31:31 <spot> hircus1: i am ignoring the FHS violations that happen as soon as you install a third party nix package
16:31:42 <abadger1999> yeah, /var/lib/nix is probably better.
16:31:52 <spot> but yeah, /var/lib/nix is cleaner
16:32:08 <spot> the nix-format is fundamentally FHS-incompatible
16:32:30 <spot> Okay. moving on.
16:32:45 <spot> #topic Recommend using %make_install - https://fedorahosted.org/fpc/ticket/183
16:33:06 <spot> i'm not crazy about this. i confused it with %makeinstall initially.
16:34:08 <spot> but el6 and all active Fedora releases should support it
16:34:22 <spot> so i'm not going to lose sleep over it
16:34:23 <hircus1> so this will mean another thing that we have to conditionally use if a package support el5
16:34:31 * abadger1999 confused it too
16:34:38 <rdieter> hircus1: seems so
16:34:39 <spot> hircus1: yes, thats right.
16:34:42 <hircus1> the draft says %makeinstall is indeed the same macro
16:34:47 <spot> but i think thats inevitable
16:34:59 <abadger1999> I think I'd be against recommending it But I would be okay mentioning it equally.
16:35:09 <abadger1999> %makeinstall is different
16:35:09 <spot> hircus1: are you sure? i don't think it says that (and it isn't the same macro)
16:35:12 * abadger1999 re-reads draft
16:35:21 <rdieter> it doesn't from my reading of it either
16:35:21 <Rathann> k
16:35:25 <Rathann> it says:
16:35:27 <Rathann> Note: %makeinstall is bad and wrong and is only left in upstream RPM for compatibility.  %make_install is the new and recommmended method.
16:35:44 <Rathann> I'm -1 on it though
16:35:46 * spot keeps hoping that RPM will kill off %makeinstall
16:35:54 <Rathann> people will make typos
16:36:02 <Rathann> and end up using %makeinstall
16:36:09 <Rathann> unless what spot said
16:36:32 <spot> I think I'm -1 to making it the recommended default, but +1 to mentioning it as existing
16:36:40 <rdieter> meh, no strong feelings, I'm +1 for the draft.  would be happy with abadger1999's suggestion to mentioning equally too
16:36:44 <abadger1999> well.... %makeinstall could still be useful when things don't support DESTDIR.
16:36:52 <abadger1999> although you have to be careful nothing gets recompiled
16:37:11 <spot> abadger1999: except that %makeinstall rarely works as expected, and it is usually just as easy to add DESTDIR support
16:37:16 <hircus1> spot: ah yes, I just checked and they expanded differently. misread the draft to mean that it just points to %make_install
16:37:20 <Rathann> abadger1999: in such cases you usually end up with hardcoded paths to the build dir in the binary
16:37:31 <limburgher> abadger1999:  I just skip make install altogether and write my own installers.  Less painful, BION.
16:37:32 <abadger1999> spot: true... I've added DESTDIR to a few packages.
16:38:02 <abadger1999> Rathann: That's what I mean about being careful about recompilation
16:39:46 <abadger1999> For mentioning, I'd change the "No %makeinstall" section to say:
16:39:58 <Rathann> yes, but it's a lot less trouble in the long run to just add DESTDIR support
16:40:16 <spot> How about simply adding a Note to the %makeinstall section describing that %make_install exists, and is identical to make DESTDIR=%{buildroot} install, but to be very careful when using it as you do not want to accidentally use %makeinstall.
16:40:39 <abadger1999> Instead, Fedora packages should use: %make_install (Note the "_"!), make DESTDIR=%{buildroot} install or make DESTDIR=$RPM_BUILD_ROOT install.  Those all do the same thing.
16:40:57 <spot> abadger1999: yeah, i'm fine with that change.
16:41:05 <limburgher> +1 #leastworst
16:41:13 <spot> +1 to abadger1999's proposal
16:41:26 <abadger1999> +1
16:42:19 * spot notes that rdieter earlier gave a +1 to this proposal
16:42:36 <Rathann> spot: I don't object to that, +1
16:42:58 <spot> geppetto: want to toss in a vote here?
16:43:11 <spot> Rathann: i'm assuming that +1 applies to abadger1999's specific implementation?
16:43:28 <spot> which is basically the same as what i suggested.
16:43:33 <Rathann> yes
16:44:00 <geppetto> meh … +1
16:44:34 <spot> #action abadger1999's suggestion to amend the language to "Instead, Fedora packages should use: %make_install (Note the "_"!), make DESTDIR=%{buildroot} install or make DESTDIR=$RPM_BUILD_ROOT install.  Those all do the same thing." is approved (+1:6, 0:0, -1:1)
16:44:42 <spot> (the -1 is racor, via ticket)
16:45:30 <spot> #topic Various scriptlets on ScriptletSnippets assume /bin/sh is bash - https://fedorahosted.org/fpc/ticket/184
16:45:33 <Rathann> put the not in big red letters ;)
16:45:36 * spot wonders if it is 1986.
16:45:49 <spot> silly time machine keeps going back there
16:45:58 <Rathann> *the note
16:46:21 <spot> Proposal: State the obvious, /bin/sh is bash in Fedora.
16:46:28 <rdieter> +1
16:46:29 <limburgher> spot: +1
16:46:34 <spot> +1
16:46:43 <hircus1> imagine all the space we could save :)
16:47:00 <geppetto> +1
16:47:06 <abadger1999> +1
16:47:41 <Rathann> hm
16:47:55 <Rathann> +1 from me
16:48:06 <Rathann> seeing as /bin/sh is owned by bash package
16:48:20 <spot> #action State the obvious, /bin/sh is bash in Fedora. (+1:6, 0:0, -1:0)
16:48:26 <spot> #topic Open Floor
16:49:53 * limburgher watches tumbleweed go by
16:49:59 <spot> okay, that works for me
16:50:02 <hircus1> there were some minor clarifications I submitted
16:50:09 <spot> hircus1: ticket #?
16:50:13 <hircus1> one sec
16:51:07 <limburgher> oh, also 176 needs to be done, spot, do you have an announcement in progress, or is this something someone else could jump in and do?
16:51:19 <spot> i do not have an announcement in progress
16:51:27 <hircus1> 181 and 182
16:51:29 <spot> if anyone wants to do the pending writeups and announcement, they would be my hero
16:51:42 <spot> 181 is fixed
16:51:43 <hircus1> oh wait, nevermind
16:51:55 <spot> and 182 is fixed.
16:52:04 <spot> we usually just do easyfix items without an announcement
16:52:15 <hircus1> yeah, didn't notice the emailed reply from trac. sorry
16:52:16 <limburgher> Ok, I'll look at 176 at least.
16:52:25 * abadger1999 just did 183
16:52:57 <spot> abadger1999: if you put the announcetext in 183, i'll do some writeups after lunch, i promise.
16:53:25 <spot> same goes for limburgher and 176
16:53:37 <spot> hircus1: thanks for your help!
16:53:41 <spot> #endmeeting