Meeting:Packaging IRC log 20060629

Jun 29 11:04:41 spot    we're only missing Jesse and Michael now. i've left Jesse a message on ICQ, so lets get started
Jun 29 11:05:11 spot    first order of business is how we are going to decide on things
Jun 29 11:05:31 spot    imho, a majority vote seems to be the most obvious way
Jun 29 11:05:43 lutter  yeah, sounds good to me
Jun 29 11:05:57 spot    does anyone disagree with that?
Jun 29 11:06:03 thimm   As long as we remain an odd number :)
Jun 29 11:06:20 tibbs   That means six for votes to pass.  Assuming we actually have eleven members.
Jun 29 11:06:21 lutter  will we require majority of everybody or only of everybody in a meeting as long as there's a minimum number of people (say 6 or 7) ?
Jun 29 11:06:34 *       scop is back
Jun 29 11:06:47 spot    i think we have 10 members right now
Jun 29 11:06:55 spot    since michael never replied and i know he's alive
Jun 29 11:07:02 racor   I'd say absolute majority, i.e. at least 6 votes
Jun 29 11:07:12 spot    at least 6 votes seems ok to me
Jun 29 11:07:23 scop    ditto, no matter how many are present
Jun 29 11:07:34 abadger1999     Makes sense to me
Jun 29 11:07:35 spot    thus, if less than 6 are present, we'll not be able to get much done. :)
Jun 29 11:07:43 racor   right
Jun 29 11:07:55 abadger1999     Can we have votes on list as well as in IRC?
Jun 29 11:08:01 spot    I don't see why not.
Jun 29 11:08:15 spot    irc merely makes a discussion flow a little faster
Jun 29 11:08:20 tibbs   Do we need a quorum rule?
Jun 29 11:08:31 racor   can't that FESCO voting system be applied?
Jun 29 11:08:37 thimm   Isn't that the quorum rule (6 persons)?
Jun 29 11:08:45 spot    i think 6 people is the quorum rule
Jun 29 11:09:06 tibbs   Sounds good to me.
Jun 29 11:09:09 lutter  do we need to make things that formal ? I hope packaging topics won't be so controversial that we have to go through a big voting process
Jun 29 11:09:21 scop    lutter++
Jun 29 11:09:21 spot    lutter: packaging is controversy. :)
Jun 29 11:09:51 lutter  (I meant using the FESCO system)
Jun 29 11:09:51 scop    let's just try KISS now, formalize later if it doesn't Just Work
Jun 29 11:10:01 lutter  sounds good to me
Jun 29 11:10:15 spot    alright, so that is settled
Jun 29 11:10:20 thimm   Let's stick with quorum of six as long as we are 10 members in total.
Jun 29 11:10:20 spot    next item: meeting date/time
Jun 29 11:10:38 spot    thimm: yep. if we gain/lose members, we'll revisit quorum
Jun 29 11:10:44 lutter  how does this time work for everybody ?
Jun 29 11:10:46 tibbs   This time is quite good for me.
Jun 29 11:10:55 scop    works for me
Jun 29 11:11:01 thimm   OK for me, too
Jun 29 11:11:02 spot    this time is good for me as well, since i have the FESCO meeting right after it
Jun 29 11:11:08 racor   Not bad, one hour earlier would be better.
Jun 29 11:11:37 jpo     this time also works for me
Jun 29 11:12:04 abadger1999     This is good.  One hour earlier puts me into my commute to work.
Jun 29 11:12:15 lutter  racor: one earlier makes it kinda early for abadger1999 and me
Jun 29 11:12:41 spot    alright, sounds like we're sticking with this day/time.
Jun 29 11:12:46 spot    is weekly ok for everyone?
Jun 29 11:13:06 rdieter aok for me (sorry was awol there for a bit... back now)
Jun 29 11:13:11 abadger1999     fine here
Jun 29 11:13:15 thimm   ok
Jun 29 11:13:18 jpo     ok
Jun 29 11:13:19 lutter  works
Jun 29 11:13:29 scop    by default yes, but of course it should depend on open issues
Jun 29 11:13:31 tibbs   Good for me.  Hopefully we won't have too much to discuss once we work through what's currently on the list.
Jun 29 11:13:54 spot    alright. lets get to the list then. i'm just going to go down from the top.
Jun 29 11:14:07 spot    the list of todo items is here:
Jun 29 11:14:08 spot    http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo
Jun 29 11:14:17 spot    First item: libexecdir
Jun 29 11:14:31 spot    is libexecdir in the FHS?
Jun 29 11:14:36 scop    no
Jun 29 11:14:45 racor   defect of the FHS
Jun 29 11:14:50 spot    i would tend to agree
Jun 29 11:14:54 tibbs   +1
Jun 29 11:14:55 thimm   It was removed at some time
Jun 29 11:15:09 scop    I think the issues are:
Jun 29 11:15:16 thimm   We should try to reintroduce it upstream
Jun 29 11:15:19 scop    wordsize of an invoking program should match the libexec one
Jun 29 11:15:47 scop    and if %{_libdir}/NAME is used instead of libexec, noarch packages can't be noarch and call these executables
Jun 29 11:16:10 tibbs   libexec should match bin, definitely.
Jun 29 11:16:19 spot    tibbs: within a package, yes.
Jun 29 11:16:19 thimm   +1
Jun 29 11:16:38 rdieter yup, +1
Jun 29 11:16:39 spot    all of these seems to make sense to me
Jun 29 11:16:40 spot    +1
Jun 29 11:16:42 abadger1999     +1
Jun 29 11:16:56 tibbs   Does the second rule impact any currently existing packages?
Jun 29 11:17:10 scop    what if let's say on x86_64 a 32-bit lib calls a libexec binary
Jun 29 11:17:13 thimm   which is "the second rule"?
Jun 29 11:17:25 tibbs   "and if %{_libdir}/NAME is used instead of libexec, noarch packages can't be noarch and call these executables"
Jun 29 11:17:32 spot    1. wordsize of an invoking program should match the libexec one
Jun 29 11:17:40 spot    2. if %{_libdir}/NAME is used instead of libexec, noarch packages can't be noarch and call these executables
Jun 29 11:18:09 thimm   I think scop didn't meant 2. to be a rule
Jun 29 11:18:20 rdieter (not that comments about %{_libdir}/name really have anything to do with _libexecdir directly... (: )
Jun 29 11:18:21 thimm   He was just giving an example of havoc :)
Jun 29 11:18:29 racor   disagree with 1. libexec/* contains executables.
Jun 29 11:18:29 spot    scop: i think we can only enforce bit size parity inside a package
Jun 29 11:18:49 rdieter racor: why?
Jun 29 11:18:58 scop    yep, those were just random issues off the cuff, not meant as rules
Jun 29 11:19:25 spot    well, lets make some rules then.
Jun 29 11:19:27 racor   wordsizes don't matter on executables
Jun 29 11:19:28 scop    spot, in that case, 2) wouldn't be an issue
Jun 29 11:19:37 *       f13 (n=me@fedora/ender) has joined #fedora-packaging
Jun 29 11:20:07 f13     sorry, I'm on the phone a bit.
Jun 29 11:20:08 spot    Rule 1: %{_libexecdir} is permitted for use by packages, even though it is not in the FHS
Jun 29 11:20:20 thimm   f13=Jesse?
Jun 29 11:20:23 spot    thimm: yep
Jun 29 11:20:30 f13     thimm: indeed.
Jun 29 11:20:33 scop    s|%{_libexecdir}|/usr/libexec|
Jun 29 11:20:58 rdieter I suppose we could go with the ml suggestion, that %_libexecdir must contain only binaries that match those in %_bindir
Jun 29 11:21:08 spot    is libexecdir ever not /usr/libexec ?
Jun 29 11:21:19 spot    _libexecdir        %{_exec_prefix}/libexec
Jun 29 11:21:19 f13     spot: I've never seen it that.
Jun 29 11:21:19 thimm   scop: why not a macro?
Jun 29 11:21:32 scop    we're not discussing a macro here
Jun 29 11:21:39 scop    FHS doesn't have macros
Jun 29 11:22:07 rdieter afaik, by default, %_libexexdir expands to %_exec_prefix/libexec (ie, they end up being the same, unless packager overrides it)
Jun 29 11:22:10 scop    %configure --libexecdir=%{_libdir}/%{name} ...
Jun 29 11:22:12 spot    Rule 1: /usr/libexec (aka %{_libexecdir} in Fedora rpm) is permitted for use by packages, even though it is not in the FHS
Jun 29 11:22:15 thimm   Well, we're extending the FHS to include /usr/libexec, but should use %{_libexec} in packages
Jun 29 11:22:17 f13     right, but we're discussing what makes sense for Fedora.
Jun 29 11:22:47 scop    spot++
Jun 29 11:22:52 f13     I agree with spot.
Jun 29 11:23:05 *       lutter nods
Jun 29 11:23:20 spot    everyone chime in on that one so we can move on?
Jun 29 11:23:21 scop    by the way, packaging guidelines doesn't really mention FHS much at all
Jun 29 11:23:28 scop    +1
Jun 29 11:23:29 abadger1999     Good rule: +1
Jun 29 11:23:29 tibbs   +1
Jun 29 11:23:31 thimm   +1
Jun 29 11:23:32 jpo     +1
Jun 29 11:23:32 rdieter +1
Jun 29 11:23:42 spot    ok, thats 6.
Jun 29 11:24:13 thimm   BTW since FHS doesn't give rationale for libexec the guideline should mention a small definition
Jun 29 11:24:13 scop    spot, if you add that to guidelines, could you add a small blurb about following the FHS in general?
Jun 29 11:24:44 spot    i think it is worth adding some text above following the FHS and have this as the exception
Jun 29 11:24:46 racor   IIRC, libexecdir is defined by the GCS
Jun 29 11:24:58 abadger1999     Yes, it is in there.
Jun 29 11:25:07 spot    racor: we're already violating the GCS in a few places
Jun 29 11:25:22 tibbs   Glasgow Coma Scale?
Jun 29 11:25:26 spot    and i really dont want to step in the middle of that flamewar
Jun 29 11:25:32 racor   GNU Coding Standards
Jun 29 11:25:33 spot    Gnu Coding Standards
Jun 29 11:25:51 spot    ok, do we want to add any other rules around libexecdir?
Jun 29 11:25:52 scop    GCS on libexecdir: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables
Jun 29 11:26:16 lutter  right .. the thing I was supposed to print out and burn ;)
Jun 29 11:26:32 spot    libexecdir, going once, going twice...
Jun 29 11:26:43 spot    ok. mono.
Jun 29 11:26:47 f13     who can we get to fix up rpmlint to accept libexec?
Jun 29 11:26:51 scop    hold on just a sec
Jun 29 11:26:55 scop    f13 I can and will
Jun 29 11:26:56 spot    scop: hmm?
Jun 29 11:27:08 scop    do we want to say something about subdirs in libexec or not?
Jun 29 11:27:22 thimm   Let this be a packager's choice
Jun 29 11:27:25 scop    GCS says add subdirs, but peeking into my /usr/libexec says otherwise
Jun 29 11:27:36 spot    i think this is ok for "up to packager"
Jun 29 11:27:43 scop    works for me
Jun 29 11:27:45 rdieter I suppose we could "recommend" use of subdirs.
Jun 29 11:27:51 rdieter it'll be cleaner
Jun 29 11:27:59 spot    i'm also not opposed to recommending subdirs
Jun 29 11:28:04 scop    +1
Jun 29 11:28:17 abadger1999     Recommends +1
Jun 29 11:28:18 f13     +1
Jun 29 11:28:20 thimm   I'd recommend: If upstream already used libexecdir, follow upstream, otherwise recommend subdirs
Jun 29 11:28:22 jpo     subdirs++
Jun 29 11:28:26 rdieter +1
Jun 29 11:28:36 spot    ok, thats 6
Jun 29 11:28:42 spot    any other libexecdir?
Jun 29 11:28:49 f13     thimm: that falls under 'packager preference'
Jun 29 11:29:04 spot    i'll write up the libexecdir stuff and add it today
Jun 29 11:29:14 f13     YaY Progress
Jun 29 11:29:17 spot    mono:
Jun 29 11:29:42 spot    there seem to be three open mono issues
Jun 29 11:29:49 spot    1. Redefining libdir for mono packages
Jun 29 11:29:59 thimm   Sorry, just a last thing about libexec: anyone going to try to fix next FHS?
Jun 29 11:30:14 spot    thimm: want to take it to the FHS on our behalf?
Jun 29 11:30:26 scop    anyone know why/when it was dropped?
Jun 29 11:30:34 spot    i can also try to get red hat to drive it forward via LSB
Jun 29 11:30:41 thimm   OK, will try. And will also find out why dropped and report
Jun 29 11:30:44 abadger1999     scop: It never made it into a final (was only in a draft)
Jun 29 11:30:53 spot    thimm: thanks
Jun 29 11:30:54 scop    all I can find is some bitter statements about the reasons being political rather than technical
Jun 29 11:31:03 spot    ok, lets move on to mono
Jun 29 11:31:17 f13     spot: do we have to?  (;
Jun 29 11:31:19 spot    most of the mono issues focus on one big question:
Jun 29 11:31:21 *       scop is more or less clueless about mono stuff
Jun 29 11:31:26 spot    Are mono DLLs arch independent?
Jun 29 11:31:45 spot    i think the end result answer is "yes"
Jun 29 11:32:02 thimm   Any mono expert around?
Jun 29 11:32:27 abadger1999     thimm: We'd have to subpoena someone :-)
Jun 29 11:32:36 thimm   If it's arch independent, what is it doing in %{_libdir}, and not in %{_datadir}?
Jun 29 11:32:47 tibbs   That's the question, isn't it?
Jun 29 11:32:47 rdieter from my reading of the summary, it appears most folks see the the .so's as arch independant
Jun 29 11:32:51 abadger1999     spot: My latest research supports that except for Ahead of time compilation limitations
Jun 29 11:33:07 rdieter but... the ahead-of-time compiling makes arch-dependant bits, which by default, end up in the same dir
Jun 29 11:33:08 abadger1999     .so's != arch independent -- .dlls == arch indep.
Jun 29 11:33:27 rdieter oops, I had it backward, abadger1999 is right.
Jun 29 11:33:28 lutter  so .dll's are like .jars ?
Jun 29 11:33:29 spot    and since a lot of the mono apps need the files in the same directory.
Jun 29 11:33:43 tibbs   lutter: That seems to be the best meme.
Jun 29 11:33:49 rdieter I'd say that until .dlls and .so's can be separated, use %_libdir
Jun 29 11:34:10 spot    i think as much as it is icky, we do need to use %{_libdir}
Jun 29 11:34:27 abadger1999     mono itself needs the ahead of time compiled files in the same dir if it is to find and use them.
Jun 29 11:34:30 f13     I can accept that as a failing of mono.
Jun 29 11:34:45 abadger1999     spot: I tnd to agree with sentiment and placement.
Jun 29 11:34:48 spot    OK, so how about this as a rule:
Jun 29 11:34:51 scop    do these paths propagate into other mono things (executables, config files)?
Jun 29 11:34:51 tibbs   I think we may have to just accept it.
Jun 29 11:34:51 abadger1999     s/tnd/tend/
Jun 29 11:34:56 spot    mono apps without .so files should be noarch
Jun 29 11:35:18 abadger1999     scop: They definitely go into pkgconfig files.
Jun 29 11:35:28 spot    all mono apps should use %{_libdir}, without redefining it
Jun 29 11:35:40 f13     how is this different from python files that get .pyc?  are not .pyc arch dependent?
Jun 29 11:35:53 scop    no, .pyc and .pyo are noarch
Jun 29 11:36:01 scop    abadger1999, that's ok
Jun 29 11:36:06 f13     ah ok.
Jun 29 11:36:29 lutter  I don't see how mono can use %{_libdir} and build noarch packages; %{_libdir} is arch dependent
Jun 29 11:36:31 scop    just thinking about real %config files, that could cause some pain if the dirs change afterwards
Jun 29 11:36:40 spot    lutter: _libdir on noarch is /usr/lib
Jun 29 11:37:02 lutter  spot: oops .. thanks
Jun 29 11:37:13 abadger1999     spot: Err... Then what happens to ahead of time (aot) compiled files?
Jun 29 11:37:20 tibbs   I think we need to pick apart a couple of real Mono packages.  Otherwise I simply have no idea what it really wants to put where.
Jun 29 11:37:23 rdieter lutter: mono apps that use %_libdir then ought not be .noarch.
Jun 29 11:37:26 spot    abadger1999: i've not see an aot file without .so files
Jun 29 11:37:34 thimm   # uname -m; find /usr/lib/mono/ -name \*.dll \! -type l | xargs file|awk -F: '{print $2}' | sed -e's,  *, ,g' | sort | uniq -c | sort -n
Jun 29 11:37:34 thimm   x86_64
Jun 29 11:37:34 thimm       174  MS-DOS executable PE for MS Windows (DLL) (console) Intel 80386 32-bit
Jun 29 11:37:47 thimm   does that make sense???
Jun 29 11:37:47 spot    thimm: file is lying there, it doesn't know any better
Jun 29 11:37:53 thimm   ok
Jun 29 11:37:59 abadger1999     spot: Yes.  But the aot's can be generated by the system administrator.
Jun 29 11:38:16 thimm   Are aots part of the dlls?
Jun 29 11:38:30 thimm   Or part of the so?
Jun 29 11:38:31 abadger1999     No -- aot's get created as .so's by mono.
Jun 29 11:38:32 tibbs   abadger1999: Really?  Should the package %ghost them?
Jun 29 11:38:36 lutter  are we sure that aot's and dll's never get mixed in the same package ?
Jun 29 11:38:45 abadger1999     tibbs... Hmm.. I'd say yes.
Jun 29 11:38:50 thimm   So then, dlls era indeed noarch
Jun 29 11:38:56 thimm   s/era/are/
Jun 29 11:39:16 abadger1999     lutter: they can be created by the packager.
Jun 29 11:39:19 spot    so, with ghosted .so files, we're ok to be noarch
Jun 29 11:39:30 spot    if they're actually present, then we're not noarch
Jun 29 11:39:36 abadger1999     lutter: I don't think they're created by default in most packages
Jun 29 11:39:41 tibbs   DLLs are noarch but something may come through and create AOTs which have to be in the same place and are NOT noarch.
Jun 29 11:39:45 tibbs   Is that accurabe?
Jun 29 11:39:46 *       scop is confused
Jun 29 11:39:55 abadger1999     tibbs: Yes.  accurate.
Jun 29 11:40:08 f13     ugh, thats still gross.
Jun 29 11:40:10 abadger1999     too me it's a tool problem.
Jun 29 11:40:11 spot    can we force all .so to be ghosted? will they be created later?
Jun 29 11:40:23 tibbs   So unless we symlink or forbid AOTs, DLLs cannot be in /usr/share.
Jun 29 11:40:26 spot    perhaps run mono in %post to create them?
Jun 29 11:40:42 scop    but they can't be in _datadir
Jun 29 11:40:42 thimm   What happens with aots when on y86_64 you call a mono bin with setarch i386?
Jun 29 11:40:45 abadger1999     mono will not search for AOTs in other places so they can't be separated.
Jun 29 11:40:50 thimm   Will it suddenly create aots for 32 bits?
Jun 29 11:41:07 spot    thimm: i don't know.
Jun 29 11:41:16 rdieter yucky alright.
Jun 29 11:41:17 tibbs   Mono can be made to do anything if someone's willing to hack it.
Jun 29 11:41:33 spot    tibbs: upstream isn't willing to take those patches as far as i can see
Jun 29 11:41:36 thimm   Maybe aots need to go to /var?
Jun 29 11:41:46 thimm   We want /usr to be stateless
Jun 29 11:41:57 tibbs   thimm: They MUST be in the same directory according to upstream.
Jun 29 11:41:58 lutter  I thought .dll and aot's need to be in the same dir ?
Jun 29 11:42:02 spot    thimm: doesn't python screw with that? :)
Jun 29 11:42:12 thimm   I thought "Mono can be made to do anything" :)
Jun 29 11:42:29 tibbs   And if upstream won't take patches then either Red Hat deviates or we just punt.
Jun 29 11:42:41 thimm   Yes, python would also violate that
Jun 29 11:42:44 rdieter by punt, meaning just use %_libdir?
Jun 29 11:42:46 lutter  the requirement that .dll and aot's need to be in the same dir mean that ther can't be noarch mono packages
Jun 29 11:43:08 rdieter right. not .noarch and use %_libdir (afaik)
Jun 29 11:43:13 spot    lutter: there are some mono apps that don't use aot .so files
Jun 29 11:43:22 spot    or don't package them
Jun 29 11:43:26 f13     I'm seeing a rule htere.
Jun 29 11:43:32 lutter  but if they depend on packages that do, they won't work
Jun 29 11:43:33 abadger1999     spot: Actually no mono package has to use aot iles.
Jun 29 11:43:47 spot    thus, if your package has no .so files, its _libdir and noarch
Jun 29 11:43:47 abadger1999     spot: The .so's that we are seeing in packages are mostly glue libraries.
Jun 29 11:43:51 f13     1) If your mono package creates AOT .sos from .dll files, your package cannot be noarch and you must use %{_libdir} for dlls
Jun 29 11:44:07 abadger1999     Between .dlls and system libraries written in C.
Jun 29 11:44:12 f13     2) If your mono package does NOT create AOT .sos, your package _can_ be noarch and should use datadir
Jun 29 11:44:26 abadger1999     AOT libraries are separate rom those.
Jun 29 11:44:32 abadger1999     s/rom/from/
Jun 29 11:44:37 scop    can the packager always control whether *.so are created or not?
Jun 29 11:44:55 scop    (think eg. *.pyc, *.pyo)
Jun 29 11:45:17 spot    we're running out of time here... who wants to dig into this issue some more?
Jun 29 11:45:31 abadger1999     scop: The packager can control whether AOT's are controlled during the build.  Glue libraries have to be built.  And the sys admin can choose to build A$
Jun 29 11:45:42 scop    ok
Jun 29 11:45:54 spot    abadger1999: can you write up a recommendation for next week?
Jun 29 11:45:59 thimm   Should we ask alexl@redhat.com (mono packager)?
Jun 29 11:46:13 f13     i thin kthis needs more discussion on list before a proposal can be made.
Jun 29 11:46:16 spot    thimm: i did, he doesn't want to get in it because hes not going to own mono much longer
Jun 29 11:46:28 abadger1999     I have two recommendations: Either we make them arch specific OR we pretend AOTs don't exist.
Jun 29 11:46:45 scop    but no matter how the AOTs (== *.so???) are built, during package build or afterwards, they must not end up in _datadir if they're arch dependent
Jun 29 11:46:48 spot    if they're arch specific, they all use %{_libdir}
Jun 29 11:46:59 thimm   If we force them to be arch specific we are at least on the safe side ... :/
Jun 29 11:47:06 thimm   Until we know better
Jun 29 11:47:08 abadger1999     What are the questions about AOTs/DLLs?  I'll write a summary with answers.
Jun 29 11:47:10 abadger1999     To the list.
Jun 29 11:47:31 f13     abadger1999: are AOTs always created from DLLs at mono runtime?
Jun 29 11:47:38 f13     (if they don't exist already)
Jun 29 11:47:57 abadger1999     f13: No.
Jun 29 11:48:17 abadger1999     f13: it has to be a conscious choice to compile them from the DLLs
Jun 29 11:48:24 spot    ok, before we leave mono behind, should we just hold our nose and say "arch specific, use libdir"
Jun 29 11:48:32 abadger1999     +1
Jun 29 11:48:35 lutter  +1
Jun 29 11:48:37 scop    +1
Jun 29 11:48:37 abadger1999     :-)
Jun 29 11:48:38 thimm   +1
Jun 29 11:48:39 f13     spot: I'm seeing that it could go either way.
Jun 29 11:48:43 spot    +1
Jun 29 11:48:45 f13     but sure, why not, thats the easy answer.
Jun 29 11:48:53 rdieter +1
Jun 29 11:48:57 spot    ok, thats 6.
Jun 29 11:49:04 tibbs   +1
Jun 29 11:49:07 racor   0
Jun 29 11:49:14 spot    lets just not smell the pile here and shove it aside. windows crap.
Jun 29 11:49:16 abadger1999     One thing about that -- will Core mono packages change directories as well?
Jun 29 11:49:24 *       scop giggles
Jun 29 11:49:34 spot    there are two items i want to get done today
Jun 29 11:49:36 f13     abadger1999: they should ues.
Jun 29 11:49:38 spot    ruby
Jun 29 11:49:47 abadger1999     Core mono currently uses /usr/lib/mono rather than %{_libdir}
Jun 29 11:49:54 tibbs   Ruby should be done now.
Jun 29 11:50:08 spot    %{_libdir}/%{name} is ok
Jun 29 11:50:10 f13     abadger1999: bugs are good, once we write up the rule.
Jun 29 11:50:17 abadger1999     f13: Sounds god.
Jun 29 11:50:25 spot    i meant _libdir vs _datadir
Jun 29 11:51:03 spot    i think the ruby guidelines at http://www.fedoraproject.org/wiki/Packaging/Ruby are fine
Jun 29 11:51:11 rdieter +1
Jun 29 11:51:20 tibbs   +1
Jun 29 11:51:21 *       f13 knows not ruby, but if its working currently, might as well add them
Jun 29 11:51:28 f13     I have a question about this though.
Jun 29 11:51:31 rdieter It's certainly a very good start, much better than what we have now (nothing).
Jun 29 11:51:49 spot    we can always make changes later
Jun 29 11:51:53 tibbs   f13?
Jun 29 11:52:05 f13     when we accept one of these sub things as policy, do we move it under the umbrella of the read-only packaging stuff so that random users can't make a change to it?
Jun 29 11:52:23 spot    yeah. Packaging/ is protected for change only by us
Jun 29 11:52:23 tibbs   Currently all of Packaging is read-only except for us.
Jun 29 11:52:38 f13     should we have a PackagingProposal/Foo to get it worked on, and then moved under Packaging/ later ?
Jun 29 11:52:48 f13     tibbs: not ScriptletSnippits (:
Jun 29 11:52:49 spot    +1 to f13's proposal
Jun 29 11:53:03 scop    could someone who knows the current status of ruby packaging well submit a patch for the ruby spec template in fedora-rpmdevtools?
Jun 29 11:53:12 tibbs   That's "Drafts Hierarchy" on the schedule.
Jun 29 11:53:12 spot    lutter: that would be you. :)
Jun 29 11:53:17 lutter  scop: I will do that as soon as the guidelines are approved
Jun 29 11:53:21 f13     tibbs: oh ok, sorry (:
Jun 29 11:53:22 scop    lutter, tia
Jun 29 11:53:26 spot    ok folks, vote on the ruby guidelines
Jun 29 11:53:32 spot    we still need a few more +s there. ;)
Jun 29 11:53:33 abadger1999     tibbs, lutter: So ruby requires ruby and ruby-libs?
Jun 29 11:53:35 f13     +1 if its currently working.
Jun 29 11:53:37 rdieter +1
Jun 29 11:53:43 tibbs   +1 for Ruby.
Jun 29 11:53:44 lutter  abadger1999: yes
Jun 29 11:53:47 thimm   0
Jun 29 11:53:52 lutter  +1
Jun 29 11:53:55 scop    +0
Jun 29 11:54:01 spot    with my +1, thats 5...
Jun 29 11:54:01 racor   0
Jun 29 11:54:05 jpo     0
Jun 29 11:54:21 tibbs   abadger1999: ruby requires ruby-libs
Jun 29 11:54:30 thimm   One is missing, we have 9 votes
Jun 29 11:54:43 abadger1999     Right.. So why do we say require both ruby and ruby(abi) which is in ruby-libs?
Jun 29 11:54:53 abadger1999     Why not just ruby(abi)?
Jun 29 11:54:57 tibbs   Note that the Ruby guidelines were developed in concert with Red Hat's Ruby maintainer, who made many changes to accommodate us.
Jun 29 11:55:01 spot    ruby(abi) should be sufficient
Jun 29 11:55:10 lutter  lemme check
Jun 29 11:55:24 rdieter ruby(abi)++
Jun 29 11:55:26 tibbs   You're right; I thought the statement about requiring Ruby had gone.
Jun 29 11:55:39 spot    lutter: nuke that first line then
Jun 29 11:55:44 tibbs   It was needed before the core Ruby package had included the ABI provide.
Jun 29 11:55:51 abadger1999     Okay.
Jun 29 11:55:53 abadger1999     +1
Jun 29 11:55:58 lutter  if you have any scripts in the package that want to run /usr/bin/ruby, youy need ruby
Jun 29 11:56:00 thimm   That's 6
Jun 29 11:56:05 spot    ok, ruby is approved.
Jun 29 11:56:08 spot    lutter: make it go
Jun 29 11:56:17 lutter  spot: will do
Jun 29 11:56:20 spot    last ASAP item: php
Jun 29 11:56:38 spot    http://www.fedoraproject.org/wiki/Packaging/PHP
Jun 29 11:57:12 tibbs   Did we hear back fro Joe Orton about the proposed core package changes?
Jun 29 11:57:26 spot    i didn't.
Jun 29 11:57:45 spot    tibbs: can you take this as your action item?
Jun 29 11:57:51 spot    i'll try to get Joe's attention on this
Jun 29 11:58:17 tibbs   Sorry, take what?  Hammering on the PHP guidelines more?
Jun 29 11:58:20 spot    tibbs: yes
Jun 29 11:58:26 spot    resolving the open issues
Jun 29 11:58:30 rdieter Packaging/PHP look like a good start to me... might as well "bless" it.  +1
Jun 29 11:58:47 tibbs   We have many unanswered questions there.
Jun 29 11:58:52 thimm   php- prefix in php-pear-... and php-pecl-... seems superfluous
Jun 29 11:59:07 spot    thimm: yeah, but it helps end-users
Jun 29 11:59:20 tibbs   Note also that people are currently submitting and aproving PHP packages.
Jun 29 11:59:34 tibbs   Should we declare a moratorium on PHP package approvals?
Jun 29 11:59:35 spot    tibbs: do they meet these guidelines?
Jun 29 11:59:48 tibbs   Yes, they are meeting the draft guidelines as far as I can tell.
Jun 29 12:00:19 scop    then proceed and improve them as the guidelines improve?
Jun 29 12:00:21 spot    should we approve the draft guidelines, with the notes that issues remain to be resolved?
Jun 29 12:00:31 spot    and resolve the issues as quickly as possible? :)
Jun 29 12:00:41 tibbs   Really the guidelines are good, but no php(abi) provide from the core PHP package, and
Jun 29 12:01:04 tibbs   no module-compat thing.
Jun 29 12:01:24 thimm   Can't php be rebuilt with these Provides:?
Jun 29 12:01:34 tibbs   Until we get that, requiring the base PHP version works as well as it can.
Jun 29 12:01:34 rdieter imo, we should either 'halt php package approvals' or 'bless guidelines'
Jun 29 12:01:41 spot    i vote we move the open issue to the bottom and approve the php guidelines.
Jun 29 12:01:53 tibbs   thimm: That's what we're trying to talk to Joe Orton about; he maintains core PHP.
Jun 29 12:02:02 tibbs   Seconded.
Jun 29 12:02:04 spot    tibbs and i will work on getting joe to add the abi bits to php
Jun 29 12:02:31 f13     +1
Jun 29 12:02:33 tibbs   spot: Agreed.
Jun 29 12:02:39 tibbs   +1 for PHP guidelines as is.
Jun 29 12:02:41 spot    +1
Jun 29 12:02:43 rdieter +1
Jun 29 12:02:46 abadger1999     +1
Jun 29 12:03:09 spot    thats 5...
Jun 29 12:03:10 lutter  0
Jun 29 12:03:17 thimm   0
Jun 29 12:03:27 scop    0
Jun 29 12:03:37 racor   0, don't see no need to vote, let things evolve.
Jun 29 12:03:44 spot    ok, its tabled.
Jun 29 12:03:51 spot    put it back on the agenda for next week
Jun 29 12:03:57 tibbs   So moratorium on PHP approvals?
Jun 29 12:04:03 spot    tibbs: yep.
Jun 29 12:04:20 spot    tibbs: can you email fedora-extras & maintainers?
Jun 29 12:04:20 tibbs   OK, I'll try to keep up with bugzilla to make sure everyone holds off.
Jun 29 12:04:28 tibbs   Yes.
Jun 29 12:04:37 spot    alright. thats all the time we've got for this week.
Jun 29 12:04:49 spot    i'll post the logs on the mailing list.
Jun 29 12:04:53 spot    thanks for the time guys.
Jun 29 12:05:41 scop    thanks
Jun 29 12:05:52 lutter  cool .. thanks
Jun 29 12:06:58 *       spot has changed the topic to: Channel for Fedora packaging related discussion | Next Meeting: Thursday, July 6th, 2006 16:00 UTC