16:03:57 <spot> #startmeeting Fedora Packaging Committee
16:03:57 <zodbot> Meeting started Wed Oct  7 16:03:57 2009 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:33 <spot> #topic Roll Call
16:04:55 * limburgher here
16:05:01 * SmootherFrOgZ is here
16:05:06 <racor> here
16:05:50 <spot> abadger1999, tibbs|h, rdieter_work: ping
16:08:19 <spot> i'll wait for a while to see if anyone shows up, as is, we do not have quorum
16:08:45 <SmootherFrOgZ> <nod>
16:08:52 <limburgher> <headdesk>
16:10:31 <tibbs|h> Ah.
16:12:47 <spot> okay, tibbs makes five
16:13:13 <spot> #info Absent: rdieter, abadger1999, hansg, Rathann
16:13:34 <spot> #topic https://fedoraproject.org/wiki/RPath_Packaging_Draft
16:14:07 <spot> this draft is designed to flesh out the existing rpath restrictions
16:14:13 <tibbs> I always thought the issue was "standard" paths in rpath.
16:15:02 <spot> that is the big issue, yes
16:15:16 <racor> ... and interaction with rpm
16:15:20 <spot> i think the point here is that this clarifies that somewhat
16:15:55 <racor> Q: How does rpm handle rpath's outside of "standard lib paths"?
16:16:09 <spot> racor: what do you mean by that?
16:16:13 <tibbs> I didn't realize rpm actually cared in any way.
16:16:19 <racor> I mean provides/requires: libxxx.so (...)
16:17:06 <spot> [spot@pterodactyl ~]$ rpm -ql qt --provides |grep libqsqlite
16:17:06 <spot> libqsqlite.so()(64bit)
16:17:06 <spot> /usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so
16:17:15 <spot> seems to handle it fine.
16:17:29 <tibbs> Assuming you call that "fine".
16:17:33 <racor> spot: No, this is wrong
16:17:34 * spot shrugs
16:17:46 <tibbs> But rpath isn't actually involved in figuring that out as far as I understand it.
16:17:56 <limburgher> I'd think if there was nothing in /etc/ld.so.conf.d and it wasn't in the standard paths, they'd be ignored by everything else.
16:18:12 <spot> yeah, i think that is more rpm doing simple searches for .so files
16:18:18 <racor> with rpaths outside of standard lib paths, one may have multiple libxxx.so at different places
16:19:38 * spot isn't sure how rpm is supposed to know about this, or handle it
16:19:46 <racor> IMO, rpm should either not add any Provides/Requires: libxxx.so (..) for such libs
16:20:10 <racor> or needs to use absolute files names (/usr/lib64/foo/bar/libxxxx.so)
16:20:11 <tibbs> I don't disagree, but that would seem to be a separate issue from rpath.
16:21:02 <racor> tibbs: right, it the provides/requires-system would not be more broken than it already is
16:21:11 <spot> yeah, sounds like a good item for an rpm.org ticket
16:22:29 <tibbs> Hmmm.
16:22:41 <spot> on the topic of the rpath draft, i think the narrow exception that is added here for internal libraries is reasonably acceptable
16:22:47 <racor> remember, perl's libxxx.so already have this problem
16:23:07 <limburgher> spot: I certainly don't think it would further break anything.
16:23:28 <tibbs> I agree.
16:23:37 <spot> So, +1 from me.
16:23:57 <racor> libburgher: to some extend it would: Multiple libxxx.so are more likely to happen, than they do now.
16:24:30 <tibbs> Please explain how.
16:24:52 <tibbs> The presence or absence of rpath has nothing to do with how rpm generates those dependencies.
16:24:53 <racor> +1, from me too, but ... be warned, I expect rpm to enter a crisis sooner or later because of this
16:25:11 <tibbs> Again, how do you expect that to happen?
16:25:27 <spot> racor: it would be helpful if you were willing to open a ticket with rpm.org around the issues you've highlighted here
16:25:52 <racor> tibbs: Let two package install two different versions of the same lib into different directories. You'd end up with clashing/conflicting Provides/Requires libxxx.so (...)
16:26:00 <limburgher> +1
16:26:04 <tibbs> If you stick an executable .so file anywhere in the filesystem, referenced by rpath or not, rpm will generate that dependency.
16:26:08 <tibbs> That happens today.
16:26:43 <tibbs> Changing what we allow for rpath has no bearing on what dependencies rpm will generate.
16:26:47 <racor> tibbs: correct, that's the bug.
16:27:06 <tibbs> So how can us changing the guidelines surrounding rpath cause any change to rpm dependencies?
16:27:34 <tibbs> Anyway, +1, although I do wish Toshio were around to talk about his draft.
16:27:53 <spot> SmootherFrOgZ: need your vote. :)
16:28:06 <racor> tibbs: The probability for such situations to happen will increase.
16:28:08 <SmootherFrOgZ> +1 from me (side note, check-rpaths tips is already included in rpmdev-setuptree script for .rpmmacros)
16:28:22 <tibbs> racor: Again, please supply some explanation or evidence.
16:28:34 <tibbs> It already happens today, and rpath is not involved.
16:28:45 <tibbs> (the libraries involved are merely dlopened)
16:29:13 <spot> #agreed RPath Packaging Draft passes with 5 +1, no 0, no -1
16:29:22 <racor> tibbs: yes it already happens today, ...
16:30:51 <spot> #topic https://fedoraproject.org/wiki/User:Notting/DirectoryDraft
16:32:00 <spot> moving on...
16:32:28 <spot> this seems like a reasonable improvement to the existing File/Directory ownership section
16:32:53 <spot> i think that the examples are good illustrations of the real world cases most commonly encountered
16:32:57 <limburgher> This seems like common sense, but maybe my brain has been warped by years of RPM building.  I like it.
16:33:26 <spot> this comes up rather often in reviews, so i am happy for the clarification
16:33:41 <tibbs> Wasn't rpm growing some extra functionality surrounding directory ownership?
16:33:50 <tibbs> How will these changes interact with that?
16:34:10 <spot> tibbs: people have been talking about that for years, i have yet to see anything tangible come from it
16:34:31 <limburgher> We're also 20 years away from Fusion power.
16:34:39 <spot> i think we can safely revisit this if/when rpm gains native support for directory/file ownership
16:34:41 <tibbs> I thought panu said that something was already implemented and in the pipeline.
16:34:50 <spot> well, lemme see if panu is around
16:34:59 <tibbs> Except that ownership issues  currently in our packages would make things break, so he can't turn it on.
16:35:35 <tibbs> I just think it would be prudent to make sure that we're not going to go against anything that rpm might be moving towards.
16:35:42 <spot> tibbs: is this the dir ownership thing I tried to fix before?
16:35:58 <tibbs> Not sure.
16:36:21 * spot notes that if so, this draft actually clarifies that "Note that when co-owning directories, you must ensure that the ownership and permissions on the directory match in all packages that own it."
16:36:54 <spot> it is also something that the autoqa could easily check for in the trees
16:37:00 <tibbs> Honestly I prefer filesystem packages, but I know that's not practical in many cases (like Perl modules).
16:37:44 <tibbs> abadger1999: Network problems?
16:37:52 <spot> i think filesystem packages make sense when there is a larger environment (KDE, for example)
16:38:00 <spot> and this draft reflects that
16:38:14 <abadger1999> tibbs: Little.  Had to bring the car in for maint.
16:38:21 <tibbs> Well, bash_completion.d would seem to me to qualify.
16:38:22 <abadger1999> But I'm on for a bit now.
16:38:36 <spot> tibbs: that's more of an "optional requirement" scenario
16:39:24 <tibbs> It just strikes me that /etc/bash_completion.d would be better owned by filesystem than potentially any command-line application owning that directory.
16:39:50 <spot> if we had Suggests, i would say that we'd want Suggests: bash-completion there, but since we don't, i'm okay with each package owning it with identical permissions
16:40:16 <tibbs> That's the kind of thing that really doesn't scale well.
16:40:28 <tibbs> What happens if one boneheaded package screws up?
16:40:28 * spot notes that for the record, he is not advocating in support of "Suggests"
16:40:35 <tibbs> What does rpm actually do in that case?
16:40:36 <spot> tibbs: its easy enough to catch that on autoqa
16:40:58 <tibbs> What was the other issue?  something surrounding prelink?
16:41:05 * spot doesn't know what rpm does in that case
16:41:13 <tibbs> That's another  one that I really think should be owned by filesystem.
16:42:10 <spot> i think the argument there was that filesystem was really only for "universal" directories, such as those covered in the FHS
16:42:44 <spot> items like /etc/prelink.d/ and /etc/bash_completion.d/ only come into play if prelink/bash_completion are installed
16:43:06 <abadger1999> I think I'm with tibbs though -- directories are cheap and a Fedora system should be able to expect them.
16:43:10 <spot> i don't really think "directory pollution" is a big issue though
16:43:44 <abadger1999> Would having a filesystem-fedora or fedora-filesystem package be worthwhile?
16:43:50 <tibbs> Basically, this draft indicates that we no longer really care that multiple packages own a directory, as long the permissions are OK.
16:43:53 <limburgher> I mean, better to have and not need, but. . .
16:44:06 <spot> tibbs: no, i don't think it says that
16:44:22 <SmootherFrOgZ> me neither
16:44:39 <spot> tibbs: i think it says that it is okay for multiple packages to own a directory in a scenario where the files are "optional functionality"
16:44:54 <spot> (or also, in the perl case)
16:45:02 <tibbs> Whereas today we have only the perl case.
16:45:06 <spot> tibbs: yes.
16:45:27 <spot> but practically, many people have been using the optional wording, including me
16:45:30 <racor> tibbs: No ... we actually have many such cases.
16:45:35 <tibbs> And "optional functionality" isn't defined in a way that package reviewers are going to be able to evaluate that in any context other than the package that we're reviewing.
16:45:46 <racor> it's only that perl applies it systematically
16:46:18 <spot> tibbs: yes, i think we have to leave it up to the reviewer to use common sense around whether it is optional functionality or not
16:46:38 <spot> the bash_completion.d and vim/emacs enhancements immediately come to mind
16:46:46 <tibbs> And just how do they determine this?
16:47:04 <tibbs> You can run repoquery --whatprovides /path/to/dir
16:47:06 <racor> spot: /etc/rpmlint is another such case
16:47:06 <tibbs> That's about it.
16:47:07 <abadger1999> Hmm... I jsut realized ,the perl case leaves unowned directories on the filesystem.
16:47:35 <racor> abadger: If so, this would qualify as bug somewhere
16:47:54 <abadger1999> racor: When perl is updated, the perl versioned directories become unowned.
16:47:59 <abadger1999> Correct?
16:48:18 <spot> Well, off the top of my head, i would say the rule of thumb is: Does this file enhance another package, where that other package is not necessary to be present for the primary functionality of this package?
16:48:19 <racor> abadger: May-be, I can't test right now.
16:48:27 <tibbs> I think the new package is supposed to keep owning the old directories.
16:48:50 <SmootherFrOgZ> abadger1999: correct, until sub-package own it with a rebuild
16:48:52 <spot> i think we dodge that issue by doing mass rebuilds for perl anyways
16:49:31 <abadger1999> tibbs: I mean at this level: /usr/lib/perl5/vendor_perl/VERSION/
16:49:41 <tibbs> Yes, so do I.
16:50:24 * spot doesn't really want to start a perl holy war around that exception
16:50:28 <abadger1999> :-)
16:50:53 <spot> tibbs: what do you think about my rule of thumb?
16:50:57 <tibbs> Perl's not really involved in this change, though.  Or do I need to read more closely?
16:51:01 <limburgher> <walks into minefield> But python has versioned dirs, and it cleans up?
16:51:14 <spot> tibbs: it is not involved, we are simply not removing it
16:51:31 <spot> or at least, no one has yet proposed it be amended or removed.
16:51:32 <tibbs> spot: I quess I could quibble over "enhance" but sure.
16:51:42 <abadger1999> tibbs: So the idea is -- the perl modules should always own /usr/lib/perl5/vendor_perl/VERSION/ or they should start to own it when they update?
16:51:47 <spot> tibbs: open to sugestions on alternate wording
16:52:09 <abadger1999> Gotta catch the shuttle back home.  Sorry to cut out :-(
16:53:58 <racor> abadger: perl(:MODULE_COMPAT_5.10.0) is supposed to take care about the cleanup.
16:55:01 <abadger1999> racor: Meaning that perl shouldn't be updatable until those modules are updated/removed?
16:55:22 <spot> how about: "When determining whether this exception applies, packagers and reviewers should ask this question: Do the files in this common directory enhance or add functionality to another package, where that other package is not necessary to be present for the primary functionality of this package?"
16:55:32 <tibbs> abadger1999: I think meaning that if the perl provides that compat symbol, it should also provide the directory.
16:55:38 <racor> abadger1999: Nope, updating VERSION will require a mass rebuild.
16:55:51 <racor> tibbs: correct.
16:57:10 <spot> tibbs: ?
16:57:32 <racor> boys, I've got ca. 5 mins left ... can we come to a conclusion?
16:57:38 <tibbs> spot: Sure.
16:57:55 <spot> okay, let me add that to the draft
16:59:01 <spot> okay
16:59:26 <spot> with the additional item clarifying the optional files exception, lets vote on this draft
16:59:40 <spot> +1 from me
16:59:59 <limburgher> +1
17:00:08 <racor> +1
17:00:12 <SmootherFrOgZ> +1
17:00:25 <tibbs> I guess this is better than the current situation.
17:00:31 <tibbs> So +1.
17:00:38 <spot> #agreed DirectoryDraft passes with 5 +1, no 0, no -1.
17:00:42 <tibbs> I just think it's fail to have 30 packages owning /etc/prelink.conf.d.
17:01:35 <spot> so, the other item on today's agenda was the CommonVoiceData draft
17:01:46 <spot> but i would like to hear from abadger1999 before we move forward on that
17:02:15 <spot> especially since the draft hasn't been changed since august
17:02:34 <spot> So, i'm going to go ahead and open the floor
17:02:37 <spot> #topic Open Floor
17:03:22 <tibbs> Does anyone know why our  spec templates break our rules for consistent use of macros?
17:03:42 <spot> tibbs: they shouldn't. pls file bugs.
17:04:04 <tibbs> They have since the beginning of time, and I've seen handwaving that there's a reason for it.
17:04:06 <spot> or, if they're in the guidelines, just fix them.
17:04:15 <tibbs> They're in a package.
17:04:20 <tibbs> Trying to find it now.
17:04:33 <spot> file bugs. feel free to cc me
17:04:54 <spot> i am unaware of any reason why that would be acceptable
17:04:57 <tibbs> For example, /etc/rpmdevtools/spectemplate-perl.spec
17:05:11 <tibbs> Uses %{__perl} but "make", "rpm", "chmod", etc.
17:05:25 <tibbs> This is a continual source of annoyance in reviews.
17:05:26 <spot> that's not necessarily inconsistent
17:05:34 <tibbs> There's the handwaving.
17:05:44 <tibbs> If someone could just explain how that's consistent....
17:05:51 <spot> it would be inconsistent if %{__perl} and perl were used
17:06:24 <tibbs> That's not how I've interpreted the rules.
17:06:27 <nim-nim> tibbs: if you find any inconsistency in the templates  shipped with fontpackages-devel please let me know
17:06:29 <tibbs> I've been wrong for years?
17:06:47 <spot> i think the reason that %{__perl} is used is specifically because it is reasonably common for perl devs to have a local copy of perl
17:06:51 <tibbs> If you want those macro forms for some whacked reason, you  should use the macro forms where you can.
17:06:55 <spot> and we want to ensure that the system copy is used
17:07:09 <spot> whereas, local copies of make, rpm, chmod are far less likely
17:07:34 <tibbs> I honestly fail to see how that actually matters for anything relevant to packaging.
17:07:54 <racor> I've  got to go, bye
17:07:54 * spot thinks that it is probably immaterial
17:08:15 <tibbs> Too bad Toshio left; I asked him if that argument was relevant to python and he said that he couldn't come up with a case where it would be.
17:08:41 <tibbs> Basically, if what's in those templates is acceptable, from this point forward I will completely stop looking at that kind of thing in package reviews.
17:08:49 <spot> tibbs: i doubt anyone will be able to make my argument hold water
17:09:03 <spot> tibbs: go ahead and bugzilla it to be patched out of the template
17:09:25 <tibbs> I wish we could just make that macro stuff just go away.
17:09:43 <spot> although, it is worth stating that my intent was for internal consistency on a per macro basis within the spec, as opposed to overly stylistic
17:09:59 <tibbs> But some people really, really like holding down the shift key and typing symbols.
17:10:18 <spot> tibbs: feel free to open an rpm.org ticket to kill it, but be prepared for the onslaught of hate
17:10:19 <limburgher> tibbs: Agreed, but it can be useful.  At $_DAYJOB I ahve to maintain versions of python modules for 2.4, 2.5 and 2.6.  Macros save lives.
17:10:46 <tibbs> Uhhh...
17:10:55 <limburgher> Yeah.
17:11:00 * spot seems to recall that SuSE heavily uses those macros
17:11:34 <tibbs> I guess I can ask that BuildRoot: and the rm -rf in %install be removed from those templates as well.
17:12:05 <limburgher> tibbs: We still need those in EPEL.  How do we address that?
17:12:21 <tibbs> You need a lot of things in EPEL.
17:12:35 <spot> limburgher: my plan was to have an EPEL specific guidelines section, and have notes that link to it in relevant sections
17:12:47 <limburgher> tibbs: True.
17:12:51 <tibbs> EPEL needs to start its own pages for documenting differences between  modern packaging and what they need.
17:12:52 <limburgher> spot: Ok.
17:13:12 <tibbs> If we can't advance Fedora packaging for seven years because of EPEL, we have real problems.
17:13:20 <spot> tibbs: agreed.
17:13:43 <limburgher> tibbs: Mos Def.
17:13:47 <tibbs> I also  think it would be good for EPEL to cook up some shim packages so things like Requires: tex(latex) will work.
17:16:28 <spot> okay, i'm closing this meeting out
17:16:30 <spot> thanks everyone
17:16:34 <spot> #endmeeting