16:01:58 <spot> #startmeeting Fedora Packaging Committee
16:01:58 <zodbot> Meeting started Wed Dec 15 16:01:58 2010 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:16 <spot> #meetingname fpc
16:02:16 <zodbot> The meeting name has been set to 'fpc'
16:02:20 <spot> #topic Roll Call
16:02:30 <geppetto> here
16:03:09 <racor> here
16:03:09 <spot> abadger1999, racor, rdieter_work, abadger1999, SmootherFrOgZ, tibbs : ping
16:03:23 * abadger1999 here
16:03:24 * jsmith lurks
16:03:28 <tibbs> I'm here, but at work today so I may be in and out.
16:04:02 * abadger1999 first day back from vacation so I haven't done any homework.
16:04:20 <tibbs> I have been away for several days as well.
16:04:20 <spot> abadger1999: no worries, i think we'll have a lite agenda today
16:04:59 <spot> okay, i count exactly 5 of us...
16:04:59 <abadger1999> geppetto: ping fpc meeting
16:05:13 <abadger1999> oh  you said ping already :-)
16:05:35 <spot> #topic Arch Specific Requires - https://fedorahosted.org/fpc/ticket/2
16:05:55 <spot> this is an old one that we've never really looked at, at least, not that I can remember
16:06:06 <spot> i updated the one section that needed it
16:06:15 <tibbs> I seem to remember discussing it.
16:06:18 <spot> https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires is the draft
16:08:13 <spot> fwiw, i don't see any issues with this.
16:08:58 * rdieter_work is in-out busy @ work , ping me if any extras votes are required
16:09:23 <geppetto> I'm +1
16:09:28 <spot> +1 from me
16:09:53 <rdieter_work> +1 (while I'm here)
16:10:36 <tibbs> +1 but I'm concerned about how much needs to change.
16:10:51 <geppetto> tibbs: To be fair, they are all fixes
16:11:02 <tibbs> Or rather, how many packages will need to change to adapt to this.
16:11:21 <spot> yeah. i think its the sort of thing that deserves to be tackled in rawhide.
16:11:24 <tibbs> How far back does the _isa macro go?
16:11:39 <geppetto> all current releases now
16:11:44 <geppetto> Well, not EPEL-5
16:11:45 <tibbs> It should be in all supported Fedora releases, sure.
16:11:59 <tibbs> But EL4 and EL5...
16:12:03 <geppetto> I think it was F-12, but maybe it was F-11
16:12:12 <rdieter_work> using %{?_isa} should be safe everywhere (note the ?)
16:12:14 * spot will add notes about EPEL and a link to the EPEL specific page
16:12:32 <spot> duh. rdieter is right. :)
16:12:35 <tibbs> True.
16:12:54 <spot> although, it would not hurt to add a note reminding people that _isa doesn't exist on EL-4 or EL-5
16:12:58 <tibbs> I really wish we didn't have to use more line noise in specs, though.
16:13:17 <abadger1999> The Naming Guidelines section is just "explicit Provides" correct?
16:13:21 <spot> tibbs: unfortunately, i can't think of a better way to do this, you cannot assume this as the default
16:13:39 <spot> abadger1999: yeah
16:14:23 <abadger1999> Also, I think the Explicit Requires/Requiring Base Package section has been clarified/reworded since this was written.
16:14:41 <spot> abadger1999: i updated the Requiring Base Package item this morning
16:14:46 <abadger1999> Okay
16:14:50 <spot> abadger1999: and the Explicit Requires section is still valid as-is
16:14:56 <abadger1999> +1
16:15:03 <racor> -1
16:15:11 <spot> racor: okay, why? :)
16:15:13 <abadger1999> with adding explicit to the Naming Guidelines section.
16:15:27 <racor> "The problem" actually are bugs in yum.
16:15:57 <racor> "The change" will render all fedora packages incompatible to older Fedoras
16:16:30 <spot> racor: the SRPMS will rebuild fine on older Fedoras, and there is never any claim of package compatibility to older dists
16:16:48 <spot> a package built for F-14 is not expected to work on F-11.
16:17:22 <tibbs> And the specs as modified according to this guideline would still build on F-11.
16:17:23 <racor> but your F11-built package will stop working on F16
16:17:35 <tibbs> It would?  Why?
16:17:50 <racor> because your F16 package will R: libXXXX.%{isa}
16:18:04 <geppetto> racor: Do you have another suggestion to fix the problem?
16:18:05 <racor> which F11 doesn't necessarily provide
16:18:21 * spot is pretty sure this is why we did a mass rebuild around F12
16:18:34 <spot> (one of the reasons)
16:18:41 <tibbs> I am having trouble understanding why this is even a trivial issue.
16:18:46 <racor> geppetto: Yes. yum is able to guess on isa during installation.
16:19:16 <racor> i.e. explicit isa would only be necessary for "weird" packages
16:19:26 <tibbs> Define "weird".
16:19:42 <spot> racor: i would encourage you to file a bug with yum (and all other resolvers in Fedora), and when this draft is no longer necessary, reopen this item.
16:19:46 <racor> tibbs: Eg. some x86_64 package R: an i386 package
16:19:47 <geppetto> racor: It does, already. I recently added protected_multilib … which will kind of help, but even that "breaks" things in ways you can only fix by turning it off
16:19:52 <tibbs> If you can limit the set of packages which need this in some reasonable way, fine.
16:20:03 <tibbs> Please propose a draft.
16:20:17 <spot> #action Draft passes (+1:5, 0:0, -1:1)
16:20:36 <racor> tibbs: How? The yum guys would have to do it.
16:21:00 <tibbs> Erm, no.
16:21:12 <racor> They apparently aren't able to get it right.
16:21:43 <tibbs> I think you misunderstand or underestimate the problem.
16:22:27 <racor> tibbs: I disagree and consider this proposal  to be utterly ugly.
16:22:38 <tibbs> I don't disagree that it's ugly.
16:22:43 <tibbs> But you are proposing alternate solutions.
16:22:50 * spot would like to move on, since I don't know how productive this argument is... but if others wish to let this continue, i'll let it.
16:22:57 <tibbs> Sorry, you aren't proposing alternate solutions.
16:23:03 <tibbs> We can only consider the solution before us.
16:23:15 <tibbs> And it does solve the problem, so...
16:23:19 <skvidal> tibbs: he's proposing yum magically  solve the problem
16:23:21 <tibbs> Anyway, I'm happy to be done.
16:23:26 <geppetto> racor: If you can think of something we can do, in yum, please drop by #yum to discuss it
16:23:28 <skvidal> tibbs: despite not having sufficient information to make good guesses
16:23:37 <spot> okay. i'm moving onward.
16:23:48 <geppetto> spot: *nods*
16:23:53 <spot> #topic Encourage packages to use %check for automated testsuites provided by upstream - https://fedorahosted.org/fpc/ticket/42
16:23:59 * rdieter_work hands skvidal some pixie dust
16:24:41 <tibbs> I agree in principle with the idea.
16:25:00 <tibbs> Actually I enforce this in all of the package reviews I do already.
16:25:08 * spot does this too
16:25:35 <tibbs> Some people disagree entirely that this should be done at package build time, though.
16:25:54 <spot> He is proposing it as a SHOULD rather than a MUST.
16:26:02 <geppetto> Personally I'd prefer a MUST
16:26:08 <tibbs> MUST is too extreme.
16:26:31 <tibbs> Some test suites take hours, require network access or an X server, etc.
16:26:34 <geppetto> It's just too easy to think "well this tiny patch couldn't hurt anything … and just build it"
16:26:49 <spot> "If the source code of the package provides a test suite, it should be executed in the %check section, whenever it is practical to do so."
16:26:51 <tibbs> However, there are people who believe that %check should never be used at all.
16:27:08 <tibbs> Because the buildsystem is entirely the wrong place to do testing.
16:27:24 <tibbs> Not that I care, but I'm just pointing it out.
16:27:28 <geppetto> tibbs: I think it's fair to say if the testuite won't run in %check it's fine to not have it there :) … but I'm not sure I care about the time thing
16:27:46 <tibbs> geppetto: Well, there's a difference between "won't run" and "takes four hours".
16:27:53 <abadger1999> limburgher: Welcome
16:27:59 <pjones> spot: I think it has to be a should.  Imagine me writing a test suite for python-pyblock. %check wouldn't be entirely appropriate.
16:28:03 <racor> good proposal, except that I would mandate running a testsuite.
16:28:07 <tibbs> And there are solutions to set up a virtual X server to run a test suite.
16:28:12 <abadger1999> limburgher: We're presently discussing https://fedorahosted.org/fpc/ticket/42
16:28:18 <tibbs> Except that you can't mandate running a test suite.
16:28:21 * spot does think it needs to be a should here.
16:28:29 <rdieter_work> fwiw, I'm +1 to this proposal (should)
16:28:33 <racor> tibbs: Certainly we can.
16:28:39 * geppetto shrugs … again I don't think 4 hours is that big a problem, given that it's at least 12 hours (ave.) to get into rawhide
16:28:53 <tibbs> I mean, I gave several arguments already.
16:28:55 * spot has come across lots of broken/incomplete/invalid test suites where there is no value to running them at all
16:28:59 <limburgher> abadger1999: thanks, sorry I'm late.
16:29:05 <rdieter_work> geppetto: or even only periodically running it, not necessarily for *every* build.
16:29:11 <abadger1999> I'm +1 as well.
16:29:15 <spot> encouraging it with packagers is the best that we can hope for
16:29:19 <spot> +1 (should)
16:29:22 <geppetto> +1
16:29:22 <tibbs> +1 (should)
16:29:43 <limburgher> +1 should
16:29:50 <racor> spot: I came across a lot of broken testsuites, also, but I also came across many testsuites which detected serious issues.
16:29:52 <tibbs> You could do "must, if reasonably possible" or something, I guess.
16:29:59 <racor> -1 (should), +1 must
16:30:04 <wwoods> test suites should probably get run in autoqa - outside the build system, as tibbs says
16:30:06 <spot> tibbs: that is roughly what "should" means in the guidelines.
16:30:37 <limburgher> racor: Would it be too much of a can of worms to start patching broken test suites?
16:30:48 <wwoods> I assume having the %check section present doesn't imply it will get run during every build?
16:31:01 <spot> wwoods: %check is executed on every build
16:31:06 <tibbs> It does imply that it will be run every build.
16:31:07 <wwoods> boo.
16:31:14 <tibbs> It's what we want.
16:31:27 <tibbs> I mean, there's a long history of running test suites at build time.
16:31:33 <racor> limburgher: No. it's what have  been doing for perl ever since Fedora is around.
16:31:40 <tibbs> Certainly doesn't mean you can't run them at other times, sure.
16:31:46 <racor> works quite well.
16:31:46 <limburgher> racor: Cool.
16:31:54 <tibbs> But you'd have to package the test suites somehow.
16:32:00 <tibbs> And.... no.
16:32:14 <racor> last resort always is "make check || :"
16:32:31 <tibbs> Now, php modules generally have test suites which can not be  run at build time.
16:32:48 <wwoods> so really, you want %check only for packages where the builtin test suite is a useful, functional post-build test
16:33:11 <racor> tibbs: I am talking about packages with integrated testsuite: Most perl modules, eg. have one. Many, esp. "big packages" also have one (e.g. perl itself, gcc, gdb, binutils, ...)
16:33:27 <pjones> wwoods: right, that's what I was saying above (about why it absolutely must be SHOULD rather than MUST)
16:33:34 <limburgher> racor: right, the 'make check' sorts of things.
16:34:12 <tibbs> racor: PHP modules have integrated test suites.
16:34:16 <spot> #action "If the source code of the package provides a test suite, it should be executed in the %check section, whenever it is practical to do so." passes (+1:6, 0:0, -1:1)
16:34:18 <geppetto> pjones: Again, I meant MUST as in … if the testuite works you MUST have it in %check … not that you have to write one
16:34:18 <tibbs> You just can't run them at build time.
16:35:00 <geppetto> pjones: I think that's pretty reasonable interpretation of MUST there … I guess I'm just wondering when we want people to not do it
16:35:14 <pjones> geppetto: which still sounds wrong, but we may just be talking around each other.  If the test suite is appropriate to use in %check, it goes in.
16:35:46 <geppetto> So … to any of the people who want SHOULD not MUST … when do you not want the tests to run?
16:35:48 <spot> my main concern around a MUST is that i know people will insist that broken/useless/irrelevant test suites be run in %check
16:36:20 <geppetto> spot: Ok … can we not just say that then … _If_ you have a testsuite that works, then you MUST run it in %check
16:37:08 <spot> geppetto: its not just "testsuite works", its also "testsuite is relevant" and "testsuite is useful" and "testsuite is not so fragile that it only works one out of every 10 runs"
16:37:13 <geppetto> My main worry is that people will go "meh, it's too annoying to put it in %check (even though it's useful/etc) and it's only SHOULD so I'll just skip it
16:37:14 <limburgher> I think the main concern is valid test suites on frequently updated pacakges that take a long time to run.  If we go with MUST, then someone's going to ask for an exception process.
16:37:28 <limburgher> gepetto: valid.
16:37:35 <limburgher> geppetto: valid.
16:37:36 <spot> geppetto: in general, we have not had that problem with SHOULD items
16:37:55 <tibbs> I have to leave for a few minutes.
16:37:58 <limburgher> Most SHOULDs make the pacakger's life easier over the long haul.
16:38:00 <spot> if we do see that, we can revisit it and make it a paragraph of MUST with exceptions
16:38:24 <geppetto> spot: For instance … zsh testuite is pretty fragile, having weird artifacts on non-normal arches … and not liking certain chroots etc. … but I keep it on
16:38:53 <racor> geppetto: Exactly. This is what typically is happening when people don't understand why a testsuite produces "weird results". In many cases people switch off all-tests, because they suspect the testsuite to be broken and don't investigate in depth.
16:39:05 <spot> geppetto: which you should do, but for a package where the testsuite is fragile and not useful, the packager should feel they have discretion to disable it without worry
16:39:27 * spot is accused daily of not giving packagers the benefit of common sense... :P
16:39:50 <geppetto> spot: You also open tickets to fix language, because common sense fails :)
16:40:11 * geppetto shrugs … as I said, I'm +1 anyway, something is better than nothing
16:40:15 <spot> imho, there are enough cases where the test suites don't need to be enabled that this crosses the line from "MUST with 10 exceptions" to "SHOULD"
16:40:28 <geppetto> Fair enough
16:40:37 <limburgher> <nods>
16:41:26 <spot> okay, so, the remaining items in trac are either not ready (systemd, mozilla, static library pic) or incomplete bundling requests
16:41:48 <spot> So...
16:41:52 <spot> #topic Open Floor
16:42:22 <abadger1999> system/tmpfiles.d stuff.
16:42:54 <abadger1999> Do we wantto make a definitive statement that %ghost ing directories in /var/run /var/lock is unnecessary?
16:43:04 <abadger1999> Since the bugs lennart opened say to do that?
16:43:21 <spot> abadger1999: i don't know that I understand the problem space well enough to comment one way or the other
16:43:50 <tibbs> back.
16:44:01 <spot> abadger1999: what are the pros/cons of %ghosting those directories?
16:44:29 <abadger1999> AFICT, simplicity is the benefit of not %ghosting
16:45:07 <abadger1999> The directory needs to be placed on the filesystem when the package is installed.
16:45:10 <geppetto> Pros: rpm -V will be happy is they are not there when the daemon isn't running. Cons: rpm -V will be happy if they are the wrong type/perms/etc. … and if they are not there when the daemon is running.
16:45:38 <abadger1999> lennart proposes %ghost of the directory and running a tmpfiles.d-some-command to create the directory in %post.
16:46:04 <geppetto> Personally I think that should be fixed in systemd, if it is overloading /var/tmp … it should manage that (creating all the dirs. etc. at bootup)
16:46:29 <abadger1999> To me it's simpler just to drop the directories into /var/run as normal directories when the package installs and tmpfiles.d will only kick in after reboot.
16:46:38 <tibbs> Well, "proposes".  As in "decided that's the way it should be and filed a bunch of bugs about it."
16:47:10 <abadger1999> How about proposes and prematurely opened a bunch of now-probably-somewhat-bogus bugs :-/
16:47:18 * spot is inclined to agree with abadger1999 here.
16:47:40 <abadger1999> The packages would still need to be modified to add the directories they need created on bootup to the tmpfiles.d configuration.
16:47:52 <tibbs> So the problem is that rpm will install directories, which after reboot simply won't be there.
16:47:57 <abadger1999> But that seems separat to whether to %ghost the directories.
16:48:19 <tibbs> Isn't this completely unrelated to systemd?
16:48:24 <spot> abadger1999: can you work up a draft that clarifies the issue and includes the fact that %ghost'ing those dirs is not necessary.
16:48:31 <geppetto> abadger1999: But why put that logic in two places in the package (changing every package using /var/tmp) … instead of just fixing systemd?
16:48:37 <tibbs> I mean, we could have switch /var/tmp to tmpfs at any point in the last decade or so.
16:49:11 <tibbs> I guess I don't understand how systemd comes into it.
16:49:55 <geppetto> tibbs: Because systemd is doing the mount … and could easily run some code which looks in the rpmdb for files in /var/tmp and re-create them
16:50:23 <geppetto> s/files/directories/
16:50:31 <tibbs> So how would it have been done before systemd?
16:50:42 <tibbs> rc.sysinit, maybe?
16:50:50 <limburgher> geppetto: Should it need to do that?  I know we're not Slackware or Debian, but how would it do this there?
16:51:02 <geppetto> Yeh, I guess … some py yum script called after the mount … I guess
16:51:13 <tibbs> That does seem rather horrible.
16:51:34 <tibbs> I mean, we're supposed to be improving boot time, not making everything hang while something trawls through rpmdb looking for directories to make.
16:51:36 <geppetto> limburgher: How would systemd create the dirs?
16:51:47 * spot thinks it would be simpler to have the package create the dir that it will need to use and not rely on any environmental hackery to create them later
16:51:50 <limburgher> geppetto: Right.
16:51:55 <abadger1999> spot: I'm not sure -- I'd like to see a statement on %ghosting directories first since lennart already filed bugs
16:52:06 <spot> abadger1999: okay, propose a statement. :)
16:52:06 <limburgher> tibbs: Plus, then you can't boot if your rpmdb is hosed.
16:52:23 * abadger1999 comes up with one real quick
16:52:28 <tibbs> spot: I guess the issue is packages that can't be modified to make their stuff for some reason.
16:52:58 <spot> tibbs: i'm not sure that i see how that is possible, unless mkdir stops working. ;)
16:53:33 <spot> then again, after working with chromium for the last four days, i think anything horrible is possible.
16:53:42 <tibbs> In the worst case you could make shell wrappers, I guess.
16:54:42 <gholms> ?
16:55:00 <abadger1999> "When we switch /var/run and /var/lock to tmpfs, directories that packages create in /var/run and /var/lock are not to be %ghosted and created in %post.  Instead, simply create the directories as normal and list them in %files.  There needs to be some additional configuration of the tmpfiles.d mechanism to handle creating those directories on reboot but the guidelines for that have not yet been written).
16:55:01 <abadger1999> "
16:55:05 <abadger1999> spot: ^
16:55:34 <spot> i'm okay with that.
16:55:35 <spot> +1
16:55:48 <geppetto> +1
16:56:00 <tibbs> Seems reasonable.
16:56:10 <abadger1999> +1
16:56:16 <tibbs> Although, what is the close parenthesis closing?
16:56:45 <spot> tibbs: there is a dangling ( in chromium. he was just helping it out. ;)
16:57:03 <abadger1999> tibbs: Sorry -- I should have done end quote instead of end parens
16:57:10 <tibbs> Ah, OK.
16:57:15 <tibbs> I'm used to lisp.
16:57:30 <tibbs> +1, but we're still short.
16:57:41 <limburgher> +1
16:57:50 <abadger1999> Ugh.
16:57:59 <abadger1999> I just reread one of lennart's bugs: https://bugzilla.redhat.com/show_bug.cgi?id=656608
16:58:02 <SmootherFrOgZ> /me just land. will scroll up to be in sync
16:58:27 <tibbs> Hmm, crap, he filed those three weeks ago.
16:58:29 <abadger1999> It doesn't mention hte tmpfiles.d mechanism at all.
16:58:38 <abadger1999> which is the real thing that people need to update.
16:58:50 <tibbs> So, huge mess all around.  Nice.
16:59:03 <spot> Well, we've got +5 here. The only thought i have is that it would be nice if FESCo ratified this.
16:59:08 <spot> so it had a little more weight behind it.
16:59:20 <tibbs> A bunch of people have already done the ghosting crap.
16:59:40 <tibbs> Should we file bugs to have them undo it, or is it OK as is?
16:59:55 <abadger1999> Depends --
17:00:03 * spot hates to play tug-of-war with packagers.
17:00:16 <abadger1999> If they followed lennart's advice in the bugs without thinking, then htey're now wrong.
17:00:16 <tibbs> I agree, but he shouldn't have filed the bugs in the first place.
17:00:42 <abadger1999> ie: %ghost without making sure that they create the directories when the package is installed will break until the package is rebooted.
17:00:45 <tibbs> We'll have to make an announcement about it in any case.
17:01:19 <limburgher> I wish there were a tracking bug so they could all be re-opened and modified if needed. . .
17:01:30 <abadger1999> Also, they won't work under tmpfs-var-run unless they also read the mailing list and realized that they have to use tmpfiles.d.
17:01:54 <tibbs> At this point we might have to get a volunteer to undo the changes made as a result of those tickets.
17:02:12 <abadger1999> yeah.  I volunteer lennart ;-)
17:02:24 <spot> i doubt he will be willing.
17:02:34 <limburgher> abadger1999: my thoughts exactly. ;)
17:02:56 <spot> we could ask FESCo to volunteer lennart, but i don't think we can.
17:03:05 <spot> https://bugzilla.redhat.com/buglist.cgi?quicksearch=Please+Update+Spec+File+to+use+%25ghost+on+files+in+%2Fvar%2Frun+and+%2Fvar%2Flock
17:03:15 <abadger1999> I don't know that FESCo can volunteer lennart either in practice.
17:03:24 <abadger1999> And it was just a joke.
17:03:33 <spot> abadger1999: :)
17:03:50 <spot> i would still like FESCo to sign off on this, to avoid the "mom says no, ask dad" play.
17:03:58 <limburgher> <nods>
17:04:08 <tibbs> At least most of them are still NEW.
17:04:32 * abadger1999 fine with sending this to fesco
17:04:39 <tibbs> Yes.
17:04:42 <abadger1999> err... sending this to fesco for approval of our statement.
17:05:47 <spot> https://fedorahosted.org/fesco/ticket/525
17:05:53 * gholms has a question whenever there's a moment
17:05:57 <abadger1999> .tiny https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc=Please%20Update%20Spec%20File%20to%20use%20%25ghost%20on%20files%20in%20%2Fvar%2Frun%20and%20%2Fvar%2Flock&bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&bug_status=CLOSED&short_desc_type=allwordssubstr&classification=Fedora
17:05:59 <zodbot> abadger1999: http://tinyurl.com/2g3fnxw
17:06:10 <abadger1999> That's the better query -- it includes CLOSED bugs.
17:06:31 <abadger1999> gholms: Go ahead
17:06:36 <spot> gholms: go for it
17:06:40 <gholms> The recent devel thread about %doc files presents a question:  what sense does it make for rpm to Provide *any* %doc files since there's no telling whether or not they will actually be installed on target systems?
17:06:48 <racor> Sorry, was chasing details  .. +1 to https://fedorahosted.org/fesco/ticket/525
17:07:29 <spot> gholms: i'm not sure i understand the question.
17:07:50 <abadger1999> gholms: Do you mean, add deps for any doc file?
17:07:54 <geppetto> gholms: If you are talking about --excludedocs … then I'd say "don't do that"
17:08:46 <geppetto> gholms: It probably works a bit better than --relocate, or --excludepath … but not much
17:09:28 <abadger1999> geppetto: Why?
17:09:45 <gholms> To clarify, the list thread mostly revolved around the fact that +x files in %_docdir get Provides entries.  But what sense does that make since the guidelines are written such that people should be able to run without doc files?
17:10:33 <gholms> Asking people to not have any scripts with +x in %_docdir seems like it's treating a symptom, not the problem.
17:10:36 <geppetto> abadger1999: Same as many other things ... because nobody tests it :)
17:10:39 <abadger1999> gholms: They don't get Provides entries --- Requires gets autoextracted for the files marked +x.
17:10:53 <geppetto> abadger1999: We also don't keep that knowledge around, so any update will undo it etc.
17:11:07 <abadger1999> geppetto: According to packaging Guidelines, anything broken by --excludedocs is a bug in the package.
17:11:16 * gholms contemplates running a system with excludedocs
17:11:48 <spot> gholms: at one point, the OLPC folks were doing that (or very much wanted to)
17:13:01 <geppetto> gholms: That would certainly be interesting … see what happens :)
17:13:03 <abadger1999> gholms: So it's unnecessary inflation of Requires that's being addressed by removing executable rather than Provides.
17:13:15 <tibbs> Now that we have yum history, there's the possibility of keeping track of installations done with --excludedocs, if yum allowed that to be passed in.
17:13:27 <skvidal> tibbs: it does
17:13:49 <skvidal> tibbs: --setopt=tsflags=nodocs
17:14:04 <geppetto> Well we wouldn't want to store it _just_ in the history, I think … putting it in the rpmdb, or at least the yumdb, would be doable though
17:14:07 <tibbs> Ah, magic.
17:14:26 * gholms gets it now
17:14:39 <skvidal> geppetto: yumdb would make sense to me - would be nice to apply those flags per-pkg :)
17:14:52 <geppetto> skvidal: Yeh, and magical ponies
17:15:05 <skvidal> geppetto: and to turn obsolete processing on and of per-element
17:15:08 * skvidal stops
17:15:09 <tibbs> Of course, when I mentioned ''yum history" I really meant all of the additional database stuff that yum keeps around.  Didn't know what you call it internally.
17:15:20 <spot> okay, we're at 17:15 now, and i am hungry for lunch.
17:15:20 <geppetto> tibbs: *nods* :)
17:15:32 <geppetto> Lunch sounds good
17:15:42 <spot> if there are no new topics, i will close this out at 17:17.
17:15:58 <tibbs> Nothing from me.
17:16:18 <limburgher> Done here.
17:16:20 <abadger1999> No more from me.
17:16:28 <gholms> Thanks, folks.
17:16:53 <spot> #endmeeting