Packaging:Minutes20070529

From FedoraProject

Revision as of 03:21, 21 December 2008 by Wikibot (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Fedora Packaging Committee Meeting of {2007-05-29}

Present

Writeups

The following drafts have been accepted by FESCO and are to be written into the guidelines:

Votes

No proposals were voted upon this week.

Other Discussions

The following additional items were discussed; see the logs for full details.

of users and groups inside rpm scriptlets. For instance, %pre cannot be allowed to fail, because it seems that it is not possible to abort an RPM transaction.

IRC Logs 

[12:01]  * f13 stumbles in
[12:02]  <tibbs> So, FPC meeting today?
[12:02]  <tibbs> I recall that we had plenty to talk about.
[12:03]  <f13> spot: ?  I know your music is playing...
[12:03]  <spot> yeah, i'm here
[12:03]  <rdieter> tibbs: blah blah static-libs blah blah... :)
[12:03]  <spot> i'm knee deep in licensing stuff.
[12:04]  <spot> ok, i count f13, rdieter, tibbs, and me
[12:05]  <scop> add one to that
[12:05]  <spot> abadger1999, lutter?
[12:05]  <abadger1999> I'm here.
[12:05]  <spot> ok, thats 6.
[12:06]  <spot> abadger1999: is the OCaml draft ready for review?
[12:06]  <abadger1999> Not yet.
[12:06]  <spot> ok.
[12:06]  <abadger1999> Richard has refined it quite a bit but I'd like to go through one more week on the lists.
[12:06]  <spot> scop: emacsen bits?
[12:07]  <scop> some progress with emacs stuff, haven't found time to look at the last round of changes
[12:07]  <spot> ok, we'll set that aside for next week too
[12:08]  <spot> scop: how about User/Groups? any changes there from last week?
[12:08]  <scop> no changes - I was supposed to add something about a registry, but the more I approached doing something the more I started to feel that it could come afterwards
[12:09]  <scop> ie. a somewhat separate issue
[12:09]  <lutter> spot: here now, sorry
[12:09]  <spot> So, there are a few changes that I'd like to see
[12:09]  <spot> 1. Use Requires: shadow-utils
[12:10]  <spot> or Requires(pre), rather
[12:10]  <spot> then, we can safely lose the pathing for the useradd/groupadd calls
[12:10]  <scop> I have no problem with that - however IIRC quite a few people prefer being explicit about stuff and requiring the exact executables we'd use
[12:11]  <spot> useradd/groupadd have been in shadow-utils for... years.
[12:11]  <scop> yeah, unless there are objections, I'll make that change
[12:12]  <spot> did anyone test to see if yum gets mad if the %pre fails?
[12:12]  <tibbs> I guess shadow-utils could grow a couple of provides, but I think it's pointless to worry about it.
[12:12]  <scop> rdieter?
[12:12]  <tibbs> I had someone wanting to require /bin/ping because it might move out of iputils one day.
[12:12]  <spot> tibbs: *shudder*
[12:13]  <rdieter> scop: sorry, -ENOTIME lately.
[12:13]  <spot> i'd feel a lot warmer about this draft if i knew yum would handle the pre failure case properly
[12:13]  <spot> skvidal: ping?
[12:13]  <tibbs> If we don't fail the pre, what would the consequences be?
[12:14]  <jeremy> %pre failing means the package won't be installed
[12:14]  <tibbs> Package gets installed with everything owned by root?
[12:14]  <spot> jeremy: what about other packages in the transaction set?
[12:14]  <spot> does yum stop entirely?
[12:14]  <spot> or packages before it in the transaction
[12:15]  <jeremy> spot: things will continue onward and you get absolutely no indication that something failed other than a line of output if you're running yum interactively
[12:15]  <jeremy> (on installs)
[12:15]  <spot> oh, that seems bad to me.
[12:15]  <jeremy> on upgrade, I think the old package remains installed
[12:15]  <spot> if foo deps on bar, and foo fails in pre, bar gets installed?
[12:15]  <spot> or rather, if bar deps on foo.
[12:15]  <skvidal> spot: pong
[12:15]  <jeremy> and yes, it is bad.  if you are intentionally making %pre fail and expecting it to mean something, you're going to lose :-)
[12:16]  <skvidal> jeremy: is this a %pre with an exit 1?
[12:16]  <scop> exit $nonzero
[12:16]  <jeremy> exit != 0
[12:16]  <spot> it seems to me like we do not want %pre to fail
[12:16]  <skvidal> so you're aborting the transaction
[12:16]  <skvidal> no, don't do that
[12:16]  <skvidal> not if you want anything to behave properly
[12:16]  <spot> and there is a pretty obvious failure case for %pre in this draft
[12:17]  <scop> instead, let the transaction go through, knowing that things won't work because it failed?
[12:17]  <spot> scop: broken system vs broken package?
[12:17]  <spot> which is the worse outcome? :)
[12:17]  <scop> "broken system"?
[12:17]  * jeremy goes to read the actual draft...
[12:17]  <spot> ok. lets say
[12:17]  <skvidal> what would be the desired failure mode?
[12:17]  <spot> libfoo and bar are being installed
[12:17]  <skvidal> ie: what is it you're hoping would happen?
[12:18]  <spot> skvidal: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
[12:18]  <lutter> we'd like the txn to abort cleanly
[12:18]  <jeremy> there is no way at all from a package to abort a transaction "cleanly"
[12:18]  <lutter> at least, don't do anything for the package whose %pre failed and any of its deps
[12:18]  <jeremy> the concept isn't even defined
[12:18]  <spot> if %pre fails on adding a user, then that package doesn't get installed.
[12:18]  <spot> but any other packages in the same transaction _do_ get installed
[12:19]  <skvidal> what?
[12:19]  <skvidal> you want it to swallow the failure?
[12:19]  <spot> uh uh.
[12:19]  <spot> i'm not advocating that at all. :)
[12:19]  <skvidal> okay, then I'm confused how is:
[12:19]  <skvidal> " but any other packages in the same transaction _do_ get installed"
[12:19]  <skvidal> not "swallow the failure"
[12:19]  <spot> ideally, i'd like to see yum detect the failure, scream, and revert the transaction entirely
[12:20]  <skvidal> revert the transaction
[12:20]  <skvidal> oh that's amusing
[12:20]  <spot> i tell yum
[12:20]  <spot> install foo bar baz
[12:20]  <spot> foo goes in fine
[12:20]  <rdieter> or abort gracefully early on...
[12:20]  <spot> bar fails in pre
[12:20]  <spot> yum does what now?
[12:20]  <jeremy> skips installing bar, nothing else changes
[12:20]  <scop> no need to revert everything, only packages that have dependencies to the one(s) that got dropped
[12:20]  <spot> but what if baz depended on bar?
[12:20]  <skvidal> b/c rpm doesn't error out
[12:20]  <jeremy> spot: baz still tries to get installed
[12:20]  <spot> will it fail because bar didn't go in?
[12:21]  <jeremy> no
[12:21]  <skvidal> jeremy: and the ts would believe it had it satisfied it
[12:21]  <jeremy> skvidal: correct
[12:21]  <spot> ok, so now we've got bar missing and baz broken
[12:21]  <skvidal> spot: no. it will happily go along
[12:21]  <lutter> ouch .. so failing %pre is really bad
[12:21]  <spot> on a larger transaction, this is DOOM
[12:21]  * rdieter thinks we're screwed. :)
[12:21]  <spot> thus, two issues.
[12:21]  <skvidal> there's no definition of failure modes for %scriptlets
[12:21]  <spot> 1. utopia: yum should be able to handle that case.
[12:21]  <spot> 2. NEVER EVER let %pre fail
[12:21]  <skvidal> if it makes you feel any better apt-deb doesn't have anything it can do then, either.
[12:22]  <lutter> spot: it's really rpm that needs to handle the failure, not yum
[12:22]  <spot> i am totally not pointing fingers there.
[12:22]  <skvidal> spot: I'm not worried, fixing this in yum would be, umm, amusing :)
[12:22]  <spot> if we're going to use %pre to add users groups, we need to have a fallout case
[12:22]  <jeremy> spot: correct
[12:23]  <skvidal> before that we need to define the modes of failure and all the cases
[12:23]  <lutter> I know .. just trying to keep tyhe moving parts styraight
[12:23]  <jeremy> (and if you're not going to use %pre to add users and groups, I'm not really sure what you're planning on doing, but hey, what do I know? ;-)
[12:23]  <-- cweyl|work has left this server (Read error: 110 (Connection timed out)).
[12:23]  <spot> skvidal: i did point out utopia, didn't i?
[12:23]  <skvidal> spot: I mean the broader definitions
[12:23]  <tibbs> Well, rpm could take care of adding users and groups internally, I guess.
[12:23]  <spot> skvidal: ok, i see what you mean.
[12:24]  <spot> so, the failure cases i see here:
[12:24]  <skvidal> spot: I mean we don't just care about adding users - all the other hurky shit out there in %scriptlets
[12:24]  <skvidal> ie: if a trigger fails?
[12:24]  <spot> skvidal: doesn't rpm throw a exit code on triggers?
[12:24]  <skvidal> I don't think it aborts the transaction anymore than a %pre error
[12:24]  <jeremy> it doesn't
[12:24]  <spot> i didn't ask that.
[12:24]  <skvidal> and I'm pretty sure it doesn't get passed up to the library layer
[12:25]  <skvidal> it's probably just emitted
[12:25]  <spot> well, eww.
[12:25]  <skvidal> no kiddin
[12:25]  <spot> so, to bring this back on topic
[12:25]  <spot> if we want to use %pre for user/group adds
[12:25]  <spot> we need to note all the possible cases
[12:25]  <spot> and plan for them.
[12:26]  <-- nim-ni1 has left this server ("Leaving.").
[12:26]  <spot> case 1: user/group doesn't exist.
[12:26]  <rdieter> or option 48: stick head in sand, pray to *diety*.
[12:26]  <spot> case 2: user/group already exists (previous package put them there)
[12:26]  <spot> case 3: user/group already exists (amanda is my username, yay!)
[12:26]  <lutter> best we can do is have the user/group additions need to always succeed; if there were problems, they need to be recorded somewhere and give ppl another tool to check for them
[12:27]  <spot> well, we can trap the exit code from useradd/groupadd
[12:27]  <spot> and say "if this exit code is non-zero, fallback to using $USER or $GROUP"
[12:27]  <scop> you can't fall back %files sections
[12:28]  <rdieter> I can't see that working, these packages (often) have hard-coded user/group references
[12:28]  <scop> you either have the user/group or not - if not, you'll get them owned by root
[12:28]  <rdieter> and if they're setuid/setgid?  (to root?)
[12:29]  * scop was thinking exactly the same
[12:29]  <jeremy> iirc, they don't get the suid/sgid bit if the right user/group doesn't exist
[12:29]  <spot> ok, so I'm slowly coming to the conclusion that there is no safe way to add users/groups in the package
[12:29]  <rdieter> jeremy: good, thanks.
[12:29]  <spot> that we need to be thinking about this differently.
[12:29]  <jeremy> (I'd have to go reread the code again to be 100% certain about it)
[12:29]  <rdieter> spot: back to 'setup'?
[12:30]  <spot> rdieter: yes, i'm thinking setup.
[12:30]  <scop> I could not disagree more
[12:30]  <spot> scop: ok, well, here's my logic path
[12:30]  <spot> pre cannot fail -> fallback will not work because %files isn't flexible
[12:31]  <rdieter> or hybrid solution, setup for well-defined users/groups ahead-of-time, and then put some (1,2, many?) place-holder user/groups there too, for use until the next iteration of setup. ?
[12:31]  <spot> the only workaround I can think of is HORRIFYING
[12:31]  <spot> and thus, i will not bring it up.
[12:31]  <lutter> spot: do anyway
[12:31]  <spot> lutter: ok. detect that we've failed in %pre with a macro define, fallback to root ownership
[12:31]  <spot> %files will do the right thing
[12:32]  <spot> check for the macro define in %post
[12:32]  <spot> and manually fix everything.
[12:32]  <tibbs> Can we do the user addition in a separate package?
[12:32]  <rdieter> the horror!
[12:32]  <tibbs> Or is that the horrifying workaround?
[12:32]  <lutter> spot: what would 'fix everything' do ?
[12:32]  <spot> chown root.root for everything in %files that had ownership perms
[12:32]  <rdieter> tibbs: I thought about that, but it doesn't buy us anything (it has most of the same problem(s)).
[12:32]  <lutter> tibbs: I think we'd run into the same problem, since rpm doesn't abort the txn
[12:33]  <tibbs> We're sure it won't abort even though the package will have unsatisfied dependencies in that case?
[12:33]  <spot> tibbs: i tend to trust skvidal when he says it won't.
[12:33]  <rdieter> tibbs: the package that adds the user would abort -> same problem.
[12:33]  <lutter> yep .. that's how I understood jeremy and skvidal said
[12:33]  <-- mdomsch has left this server ("Leaving").
[12:34]  <tibbs> I had the impression it just wouldn't stop the installation of the package with the failing pre.
[12:34]  <spot> skvidal: ok, come back, we need you to be explicit
[12:35]  <spot> yum install foo bar baz
[12:35]  <rdieter> we have the option of simply assuming user/group adds always succeed. :)
[12:35]  <tibbs> scrollback seems to indicate that I'm wrong.
[12:35]  <spot> baz depends on bar
[12:35]  <spot> bar fails on %pre
[12:35]  <spot> does baz get installed?
[12:35]  <scop> yes
[12:35]  <tibbs> Note also that we don't have to use %pre in this case.
[12:35]  <scop> ?
[12:35]  <rdieter> tibbs: %pre is still the way to go (I think)
[12:36]  <tibbs> If there were some other hook we could use that has better behavior....
[12:36]  <rdieter> tibbs: we don't want a pkg that Provides: user(foo) to get installed, then fail in %post, do we?
[12:36]  <scop> %pretrans?
[12:36]  <rdieter> %pretrans is way, way early alright.
[12:37]  <rdieter> maybe failure there is less horrifying. :)
[12:37]  <spot> i'm not sure it is.
[12:37]  <spot> any pre-install scriptlet failure will cause that package to not be installed
[12:37]  <spot> but it will not affect the transaction in-flight
[12:38]  <rdieter> ugh (we want the whole transation stopped).
[12:38]  <scop> if failing %pretrans doesn't cancel the whole transaction, that must be a bug
[12:38]  <scop> but then again I'm not sure we can always expect shadow-utils to be available for %pretrans
[12:38]  <rdieter> scop: ouch, you're right.
[12:39]  --> nim-nim has joined this channel (n=nim-nim@m37.net81-64-156.noos.fr).
[12:39]  <spot> hmm, ok. thinking out loud.
[12:39]  <spot> can we just check for the existence of the desired user/group in %pre?
[12:39]  <scop> we already do for the username
[12:39]  <spot> we don't fail if we find it, we just binary macro flip yes/no
[12:40]  <scop> eh
[12:40]  <spot> conditionalize the Provides: user(foo) around that binary macro
[12:40]  <spot> in %post, check the binary macro, add user if its not there
[12:40]  <scop> I don't think you can affect such things in scriptlets
[12:41]  <spot> are you sure?
[12:41]  <scop> 99%
[12:41]  * rdieter though macros were defined at *build* time, not runtime.
[12:41]  <spot> because that would be slippery, but it might get us over the top
[12:41]  <lutter> spot: why not wrap the user/group add in a script that (a) is somewhat tolerant to the various failure modes and (b) keeps track of what user/groups it would have liked to create; that at least gives admins a fighting chance to figure out if there were problems after the fact
[12:41]  <scop> I fail to see how that would be better than just letting %pre fail if the user/group creation fails
[12:42]  <spot> scop: ok, let me repeat. we don't ever want %pre to fail.
[12:42]  <spot> i will vote against any draft that lets %pre fail.
[12:42]  <rdieter> lutter: yeah, I think we need a helper app/scriptlet that can do more for us here.
[12:42]  <spot> ok, more thinking out loud
[12:43]  <spot> can we do this with a yum plugin?
[12:43]  <scop> no
[12:43]  <spot> why not?
[12:43]  <lutter> is there ever a situation where we are not able to run a script and have user X exist afterwards ? The user might have the wrong uid/home dir etc., but that's a sperate issue ;)
[12:43]  <scop> doesn't help apt, smart, rpm
[12:43]  <spot> i'm all for choice, but couldn't they also get plugins?
[12:43]  <spot> well, maybe not rpm. ok.
[12:43]  <tibbs> Well, rpm doesn't do plugins.
[12:43]  <lutter> I think such a script should go into shadow-utils
[12:43]  <scop> I will vote against any draft that requires writing plugins for this
[12:44]  <lutter> and there's no guarantee that ppl have that plugin enabled in yum
[12:44]  <spot> so, shadow-utils should provide a utility that adds a user/group safely, handles rpm provides, and file ownership?
[12:45]  <spot> i think we're violently slamming against the wall of what is possible with rpm
[12:45]  <scop> how would it handle rpm provides?
[12:45]  <rdieter> spot: everything but rpm provides,  yes.
[12:45]  <lutter> not rpm provides; not sure what to do about file ownership
[12:45]  <spot> Provides: user(foo)
[12:45]  <scop> but a script in shadow-utils?
[12:46]  * scop notes I have 2 smaller other things I'd like to discuss for a bit today
[12:46]  <spot> ok, lets set user/groups aside
[12:46]  <rdieter> some sort of useradd/groupadd queue (and sets perms), where stuff gets removed only on success.
[12:46]  <spot> i have some other ideas i want to try before i discuss
[12:46]  <lutter> if the user at least exists by the time %files does its thing, file ownership isn't as big an issue. To guard against the amanda situation (ordinary user suddenly can run programs they weren't supposed to) we'd need a separate way to disable such programs .. it's ugly
[12:46]  <rdieter> (this is starting to sound like some SuSE madness I've seen before)
[12:47]  <spot> scop: go ahead, whatcha got?
[12:47]  <scop> for the record, I'm now convinced that non-failing %pre is better than a failing one even if the user/group creation fails
[12:47]  <lutter> there's another, even ickier option: fix rpm to do the right thing when %pre fails (where we define 'the right thing')
[12:47]  <tibbs> %post could do some cleanup/disabling/chown to nobody if the user didn't get created, I guess.
[12:47]  <scop> 1st little thing: http://www.redhat.com/archives/fedora-packaging/2007-May/msg00116.html
[12:48]  <spot> lutter: rule number 1 of packaging club: Fixing rpm is not an option, outside of our scope.
[12:48]  <scop> I suppose fixing the scriptletsnippets page according to mlichvar's points doesn't require much discussion?
[12:48]  <spot> scop: ok, so someone should probably fix scriptletsnippers
[12:48]  <tibbs> scop: Well, what's wrong with a little defensive programming?
[12:49]  <rdieter> I think we just came to the conclusion that aborting scriplets leads to madness, and is not an option.
[12:49]  <scop> tibbs, you're referring to mlichvar's post?
[12:49]  <tibbs> scop: Yes.
[12:49]  <tibbs> We can save three characters per line if we make an assumption about the internals of rpm.
[12:49]  <scop> he points out that some of the info in ScriptletSnippets is plain wrong, and he's right
[12:49]  <lutter> I think the part that talks about omitting ||: is sane and scriptletsnipers should be updated accordingly
[12:50]  <tibbs> Doesn't seem like a terribly good tradeoff to me, personally.
[12:50]  <rdieter> I don't really see the point either.
[12:50]  <scop> "This is important because the scriptlet as a whole will error the moment it tries to execute a command that has a non-zero exit status."
[12:50]  <scop> that's incorrect
[12:51]  <rdieter> ah, that part should be fixed, the rest, not so sure.
[12:51]  <spot> any obvious errors in scriptletsnippets should be fixed.
[12:51]  <spot> that page got grandfathered in...
[12:52]  <abadger1999> scop: I agree.  That needs to be changed otherwise people will have false expectations of
[12:52]  <abadger1999> %post
[12:52]  <abadger1999> /bin/false
[12:52]  <abadger1999> /bin/true || :
[12:52]  <scop> ok, so do people want this drafted or me to just go ahead and fix any obvious errors?
[12:53]  <abadger1999> +1 Just fix it.
[12:53]  <tibbs> I guess that whole thing needs to be changed to note that we now know that you can never allow a scriptlet to fail.
[12:53]  <spot> +1 just fix it
[12:53]  <lutter> +1
[12:53]  <scop> on the other hand, if we can't allow a scriptlet to fail, that's something that our rpm which drives us into that kind of situation should have built in
[12:53]  <tibbs> I guess it depends on what you intend to just fix.
[12:53]  <rdieter> +1
[12:54]  * scop sighs
[12:54]  <tibbs> Because if you want to add mlichvar's info about appending "|| exit 1" then we'd have a problem.
[12:54]  <tibbs> But if you just want to remove the incorrect info then fine.
[12:54]  <scop> that's not in the "obvious errors" category I volunteered to fix
[12:54]  <spot> scop: why don't you draft it
[12:54]  <spot> just to make sure everyone is happy
[12:54]  --> JSchmitt has joined this channel (n=s4504kr@p54B10442.dip0.t-ipconnect.de).
[12:55]  <scop> ok
[12:55]  <tibbs> I don't want to force an extra runthrough.
[12:55]  <lutter> scop: I think you could just write a one sentence description of the change here and we vote on it right now
[12:55]  <spot> lutter: i think its more than one sentence
[12:55]  <spot> scop: you can just copy the page into PackagingDrafts
[12:55]  <spot> edit it there
[12:55]  <scop> I'll draft something for next week
[12:56]  <scop> next, including test suite code that upstream doesn't install in binary packages
[12:56]  <scop> I'm not sure if this is on our plate though
[12:56]  <tibbs> Ah, what cweyl's doing for all of his perl packages now.
[12:56]  <spot> yeah. i think i'm not really in support of this.
[12:56]  <spot> i think test suite code not installed by make install goes in -devel
[12:56]  <spot> or not at all
[12:56]  <tibbs> I have to admit it bothers me, but in many cases the example code is useful as documentation.
[12:57]  <scop> I'm not at all either
[12:57]  <spot> tibbs: not in /usr/bin
[12:57]  <spot> i don't care what goes in %doc that isn't executable. :)
[12:57]  <tibbs> OK, so this isn't what Cweyl's doing.
[12:57]  <spot> you can dump the kitchen sink in there. :)
[12:57]  <tibbs> spot: Even tarballs?
[12:57]  * spot squirms a little
[12:57]  <spot> i like that better than test binaries in /usr/bin
[12:58]  <scop> I do care about %docs as well, some rationale here: https://bugzilla.redhat.com/239193#c4
[12:58]  <tibbs> I just reviewed a package that included several empty directories and two tarballs as %doc.
[12:58]  <spot> empty dirs shouldn't be in %doc without good reason
[12:58]  <tibbs> They're needed by the "example code", aka the test suite that gets packaged.
[12:59]  * scop thinks empty dirs are less harmful than the average test suite code
[12:59]  <lutter> installing an rpm shouldn't set you up with a dev environment for that package .. at some point, you have to check out the code from upstream
[12:59]  <tibbs> So we have multiple issues.
[12:59]  <tibbs> What packages are putting test stuff in /usr/bin?
[13:00]  <spot> i think packaging up test code as %doc is alright.
[13:00]  <spot> as long as it is non-executable
[13:00]  <tibbs> Perl tests are generally non-executable.
[13:00]  <scop> hm, so the difference is "./t/foo.t" vs "perl ./t/foo.t"?
[13:02]  <spot> the former is a possible accident, the later is very unlikely to be accidental.
[13:02]  <spot> i admit it is a thin line.
[13:02]  <lutter> seems like it boils down to whether the tests are written in a compiled or in a scripting language
[13:02]  <scop> but really, test suite code in non-*-devel, non-*-test packages?
[13:03]  <tibbs> ld.so ./t/blah ?
[13:03]  <spot> scop: other than in %doc, i say no.
[13:03]  <abadger1999> Or -doc packages
[13:03]  <scop> abadger1999++
[13:03]  <scop> IMO not in main package, %doc or not
[13:03]  <tibbs> I have to agree.  Tests as documentation are suboptimal, but occasionally that's all you get.
[13:04]  <lutter> but if you are interested at that level, you might as well check out from upstream
[13:04]  <tibbs> Sorry, I was agreeing with spot, not scop.
[13:04]  *** knurd is now known as knurd_afk.
[13:04]  <spot> we shouldn't require it, but its packager's discretion to have tests in %doc, -devel, or -test
[13:04]  <spot> if its in %doc, it can't be executable (chmod -x)
[13:04]  <spot> or -doc (as %doc) if there are a lot of docs
[13:05]  <spot> but test code shouldn't be in %bindir or %sbindir
[13:05]  <tibbs> Theoretically, we could require all perl modules to split their documentation to -devel, since it's only needed by developers and not by end-users.
[13:05]  <tibbs> But that would be madness, I think.
[13:05]  * spot shudders
[13:05]  <lutter> I'd much prefer if test code be left out of the main package entirely; it's just bloat for most people
[13:05]  <spot> i can hear the knashing of teeth now
[13:06]  <rdieter> if -devel already exists, fine, but not just for docs.
[13:06]  <spot> i think if the argument is that test code is useful for -devel, there is a -devel.
[13:07]  <spot> how about (if a -devel, put it there. if not, -doc/%doc is ok for small quantities of test code)
[13:07]  <abadger1999> spot: knashing if you use kde, gnashing otherwise.
[13:07]  <spot> if not small quanties, use -test.
[13:07]  <scop> -1 to blanket approval for test code that isn't installed by upstream
[13:07]  <spot> quantities
[13:08]  <rdieter> anything else juicy, me gotta run soon.
[13:08]  * spot sighs
[13:08]  <spot> if someone cares about this enough to draft it formally, then i'll vote on it.
[13:08]  <tibbs> scop: Do you have a different opinion of example code?
[13:08]  <scop> tibbs, different than what?
[13:08]  <spot> i'm starving.
[13:09]  <tibbs> scop: You don't like test code that isn't installed by upstream, but what about an "examples" directory included as %doc?
[13:09]  <tibbs> And if you view that differently, why is test suite code not acceptable as an example?
[13:09]  <scop> well, that's pretty clearly designated as an example how to use stuff
[13:09]  <abadger1999> tibbs: Does libfl.a need anything from us?
[13:10]  <rdieter> +1 to what spot said (about test code, and starving)
[13:10]  <tibbs> abadger1999: It's FESCo that approves those, isn't it?
[13:10]  <spot> yeah, static libs ain't us.
[13:10]  <spot> we just tell you how to package them. :)
[13:10]  <tibbs> I think that FESCo kind of has to approve flex or else we break lots of things.
[13:10]  <abadger1999> I think the static library changes we voted on last week makes it so FESCo doesn't have to approve inclusion anymore.
[13:11]  <abadger1999> Just approval of linking.
[13:11]  <spot> abadger1999: i agree
[13:11]  <spot> static libraries can be packaged. static linked binaries need permission.
[13:11]  <tibbs> abadger1999: Which would mean any package that does BR: flex needs an ack?
[13:11]  <spot> (from FESCo)
[13:11]  <tibbs> Fun.
[13:12]  <spot> tibbs: FESCo could blanket approve flex linked binaries.
[13:12]  <tibbs> I think they'd have to in this case.
[13:12]  <abadger1999> tibbs: That's why I asked :-)
[13:12]  <spot> but i don't speak for FESCo as a whole. :)
[13:12]  * spot puts on his tin-foil hat
[13:12]  <abadger1999> Maybe libfl.a should be in a -devel package?
[13:12]  <rdieter> imo, yes.
[13:12]  <spot> the guidelines would say that, yes.
[13:13]  <spot> ok, one last thing before i stop the madness. ;)
[13:13]  <spot> http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
[13:13]  <spot> lutter, rdieter
[13:13]  * lutter hides (again)
[13:13]  <spot> you know what i'm going to say. get it done, pls.
[13:14]  <tibbs> abadger1999: flex itself is a "-devel" package, like gcc.
[13:14]  <rdieter> yeah, yeah.  F7-tasks are mostly done, I can catch-up on things now.
[13:14]  <abadger1999> And we could add something to the guidelines that say BR: *-static needs approval,  BR: *-devel is okay as we can get the same information out of it.
[13:14]  <rdieter> tibbs: good point, ok. :)
[13:14]  <spot> ok, folks. lunch time for me. thanks for all the headaches. :)
[13:15]  *** rdieter is now known as rdieter_away.
[13:15]  <abadger1999> Thanks spot.
[13:15]  <tibbs> Lunch!
[13:16]  <abadger1999> tibbs: Hmm... Let me think of a way to reword so we don't have to worry about flex.
Retrieved from "https://fedoraproject.org/wiki/Packaging:Minutes20070529"