From Fedora Project Wiki

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

Present

  • DavidLutterkort (lutter)
  • JasonTibbitts (tibbs)
  • JesseKeating (f13)
  • RalfCorsepius (racor)
  • RexDieter (rdieter)
  • TomCallaway (spot)
  • ToshioKuratomi (abadger1999)
  • VilleSkyttä (scop)

Writeups

No meeting last week, so no writeups this week.

Votes

The following proposals were considered:


Other Discussions

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

IRC Logs

[12:01]  * spot wakes up
[12:01]  <Kevin_Kofler> Time to bring up the compat naming stuff? ;-)
[12:01]  <rdieter> let's wait for jeremy first.
[12:01]  --> abadger1999 has joined this channel (n=abadger1@090.164-78-65.ftth.swbr.surewest.net).
[12:01]  <spot> maybe we'll have quorum this week. if not, early lunch for me!
[12:02]  * lutter looks around
[12:02]  <spot> ok, i see abadger1999, rdieter, lutter
[12:02]  <jeremy> spot: no lunch for you!
[12:02]  <spot> f13: ?
[12:02]  <abadger1999> I'm here.
[12:02]  * scop here too
[12:02]  <spot> racor?
[12:02]  <rdieter> food good.here
[12:03]  <XulChris> food?
[12:03]  <spot> ok, we've got quorum. i'll give the others a chance to awaken/arrive
[12:03]  <rdieter> bummer, food can wait I spose
[12:04]  <racor> as usual at this time frame, here, but half distracted
[12:05]  <spot> i suppose f13 isn't awake...
[12:05]  <spot> ok, lets go ahead and start
[12:05]  <spot> rdieter/lutter: reminder: writeup your guidelines!
[12:06]  <rdieter> yes, I'm bad.
[12:06]  <lutter> spot: ugh .. yeah, completely forgot
[12:06]  <spot> First item: emacs guidelines
[12:06]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns
[12:06]  <spot> those who care about emacs have written some guidelines for emacs packaging
[12:07]  <spot> no changes to existing guidelines, just new ones for emacs along with some templates.
[12:08]  <spot> any thoughts? is anyone reading them and need more time?
[12:08]  <scop> I read it through earlier once, and looks like most of my comments are now addressed
[12:08]  <tibbs> Bagh.
[12:09]  <rdieter> ugh, just wiped out -emacs bits from a few of my packages awhile back, rely on %triggers now (I forget where I stole/borrowed the idea from).
[12:09]  <scop> there are some bits still missing though
[12:09]  <spot> scop: are those bits that could be added later, or should we hold on this draft?
[12:09]  <tibbs> Folks, if I don't perk up immediately at meeting time, feel free to ping me.  The sound will help to get me out of whatever I happen to be stuck with.
[12:10]  <scop> I think they can wait
[12:10]  <scop> the only one I see at the moment is that the built packages should require >= the (x)emacs used to build the package, not some hardcoded values in specfile
[12:11]  <scop> and there were some questions about the "-common" part of "emacs-common-foo" as the main package srpm name on the list
[12:11]  <tibbs> I think we need emacs guidelines but I'm rather unqualified to judge how good the draft ones are.
[12:11]  <spot> scop: the naming questions can be brought up in a separate draft
[12:11]  <rdieter> scop: why >= exactly?
[12:11]  <scop> at least in the xemacs case, there are no guarantees that the built *.elc are backwards compatible
[12:11]  <tibbs> The naming question was beaten out a long time ago, though.  I only vaguely remember the discussion.
[12:12]  <rdieter> scop: ok.
[12:12]  <scop> rdieter, they mostly tend to be, but for example *.elc built with xemacs 21.5 will probably exhibit some more or less hard to find bugs when run with 21.4
[12:12]  <spot> it seems like that it wouldn't be too hard to ask xemacs/emacs what version it is, and macroize that
[12:12]  <rdieter> spot: +1
[12:13]  <scop> yeah, I have some of that in xemacs-packages-{base,extra}
[12:13]  <spot> scop: do you want to work with the draft author to integrate that?
[12:13]  <tibbs> We do that in plenty of other places so it makes sense.
[12:13]  <scop> spot, sure
[12:13]  <spot> we'll revisit it next week then.
[12:14]  <f13> I'm in another meeting.
[12:14]  <f13> trying to pay attention to both but...
[12:14]  <scop> I'd also like to see something about smaller elisp snippet packaging mentioned
[12:14]  <spot> next: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges
[12:15]  <spot> ralf pointed out that .la files, once included, need to stick around for the life of that Fedora release.
[12:15]  <rdieter> s/need/should/
[12:15]  <rdieter> :)
[12:15]  <spot> is it really a should?
[12:16]  <rdieter> is it worth mentioning that .la files are often required for static linking to work?
[12:16]  <scop> (for reference, "smaller elisp snippet packaging": #235431, #235437, rpmdevtools)
[12:16]  <spot> i think the logic there is that once they're in, removing them causes unexpected behavior
[12:16]  <racor> rdieter: MUST, if they have been used
[12:16]  <rdieter> spot: imo, anyway, the gain of omission is often greater than risk of "unexpected behavior", but that's just me.
[12:16]  <racor> by other *.la's
[12:17]  <scop> yep, they tend to propagate into other *.la's
[12:17]  <rdieter> racor: of course, if you *know* that's one thing.
[12:17]  <spot> i think it is easier to err on the MUST side for this one
[12:17]  <scop> I think keeping/removing *.la's falls into the same category as major API/ABI/packaging changes within a release
[12:18]  <racor> rule of thumb, ever since FE has existed: Never remove *.la's from a package once it's in
[12:18]  <scop> there are several cases where they have been removed
[12:18]  <racor> scop: ACK
[12:19]  <racor> scop: Yes, but there have been cases where they broke things
[12:19]  <abadger1999> k.  So add a note that *.la's should be treated the same as an API change?
[12:19]  <rdieter> yep (begrudgingly)
[12:19]  <spot> racor also pointed out that he'd like this added:
[12:20]  <spot> Development libraries (libraries not being used at runtime) must not be packaged in /%{_lib}.
[12:20]  <tibbs> That's reasonable.
[12:20]  <rdieter> agreed.
[12:20]  <scop> "same as other major changes affecting other packages"
[12:20]  <tibbs> We shouldn't let /lib fill up with useless crap.
[12:20]  <abadger1999> I like that.
[12:20]  <spot> They should go in %{_libdir} instead.
[12:21]  <spot> Last, but not least: ocaml appears to be retard^Wspecial
[12:21]  <spot> it needs to be exempted from this, at least for now.
[12:21]  <rdieter> So, we could get icky situations where /usr/lib/libfoo.so symlink points to /lib/libfoo.so.1 ?
[12:21]  <tibbs> ocaml is going to be the source of many nightmares, I think.
[12:22]  <racor> rdieter: Yes.
[12:22]  <spot> rdieter: better that than the other way around.
[12:22]  <tibbs> I don't see that situation as being icky.
[12:22]  <rdieter> I can see the esthetic value in that, but that's just nasty ugly.
[12:22]  <abadger1999> Wait -- ocaml needs static C libraries?
[12:23]  <tibbs> As long as ldconfig doesn't crap out on it, that is.
[12:23]  <abadger1999> Or just static ocaml libraries?
[12:23]  <tibbs> I think there's some weirdness there.
[12:23]  <racor> rdieter: It's not "just  esthetic", it's more.
[12:23]  <rdieter> racor: like?
[12:23]  <racor> consider GCC's system library path
[12:23]  <spot> "Again, OCaml binaries are always statically linked to OCaml libraries (not to the C libraries they may use however)."
[12:24]  <racor> the order of -L -lsystem matters
[12:24]  <rdieter> I don't see how /lib vs /usr/lib is affected by that. ??
[12:24]  <scop> btw, I think a full review of whether things installed in /bin, /sbin and /lib(64) have dependencies to /usr would be in order
[12:24]  <racor> hacking around on it (like glib did in Fc6) can break things in nasty subtile manners
[12:25]  <spot> abadger1999: i think you can just add an exception section that says that OCaml libraries are static, and need only to follow the naming policies.
[12:25]  <abadger1999> spot: k.  Editing.
[12:25]  <rdieter> racor: I 'spose I'll take your word on that. :)
[12:28]  <racor> sorry, i'm out-of-time for today (wife is waiting with dinner)
[12:29]  <racor> should you want to vote, consider mine as 0 on emacs (not enough clues about emacs)
[12:29]  <spot> racor: thanks for the time
[12:29]  <spot> racor: and on the static with updates?
[12:29]  <racor> and +1 on abadger's static link
[12:29]  <racor> +1
[12:29]  <scop> usersandgroups?
[12:30]  <tibbs> You can feel the enthusiasm in the air....
[12:30]  <lutter> tibbs: I think it's trembling
[12:31]  <spot> ok, lets vote on static draft with edits
[12:31]  <spot> +1
[12:31]  <tibbs> +1
[12:32]  <rdieter> +1
[12:32]  <abadger1999> +1
[12:32]  <scop> +1 (one minor change: "staticly linking executables" section also affects other things besides executables)
[12:32]  <lutter> +1
[12:32]  <tibbs> And ralf's +1
[12:33]  <spot> scop: is "binaries" a better term?
[12:33]  <scop> spot++
[12:33]  <abadger1999> scop: Or just static linkage?
[12:33]  <scop> even better
[12:33]  <spot> +
[12:33]  <spot> ok, it passes.
[12:34]  <spot> i don't think the Ocaml draft is ready yet...
[12:34]  <spot> it seems rather contentious on the lists
[12:34]  <abadger1999> spot: I agree.  The SIG is still contributing new ideas for it.
[12:35]  <spot> which brings us to everyone's favorite flame war
[12:35]  <tibbs> What's troublesome is that the language system seems antithetical to many good practises.
[12:35]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
[12:36]  <tibbs> Didn't seem to be a whole lot of discussion about this the last time it came up.
[12:36]  <tibbs> On-list, that is.
[12:36]  <spot> I would like to see a Requires(post): shadow-utils instead of the binary
[12:36]  <spot> err, pre rather
[12:37]  <scop> I think with that change, the executables invoked should be pathless
[12:37]  <tibbs> Or perhaps we could get the shadow-utils package to grow Provides: useradd
[12:37]  <spot> scop: thats fine
[12:37]  <rdieter> not necessarily true is it: Aborting with an error in %pre (as opposed to %post) doesn't trash the rpm database.
[12:37]  <rdieter> what if package in question is 1 of 10 in a transaction?
[12:38]  <scop> 2-10 proceed fine to the end, assuming their scripts don't require anything that 1 would bring to the table
[12:38]  <spot> the other idea is to trap error codes
[12:39]  <spot> notting pointed out that "There is a specific exit status for 'user already exists'."
[12:39]  <rdieter> I've seen %pre's fail, and it's not pretty cleaning up the mess.
[12:39]  <scop> rdieter, define "the mess"?
[12:39]  <rdieter> transactions not finished => multiple pkgs installed (foo-1.0 and foo-1.1)
[12:40]  <scop> rdieter, are you *sure* you've seen that caused by a failing %pre?
[12:40]  <tibbs> From the stanpoint of the guideline, though, don't we have to fail if useradd fails, regardless of whether rpm screws something else up?
[12:40]  <scop> dupes can be left behind by failing %post, %preun and %postun yes, but %pre?
[12:40]  <spot> tibbs: do we want to fail if useradd fails because the user already exists?
[12:41]  <rdieter> scop: pretty sure, I can work up a test-case if it will make you feel better, though I'd counter are you *sure* %pre can't cause what I'm describing?
[12:41]  <lutter> spot: no, that would prevent people from preassigning user id's
[12:41]  <spot> tibbs: this either means the user was pre-created specifically by the admin, or a "normal" user already chose it.
[12:41]  <scop> rdieter, well, I can't think of how would I go about constructing a test case showing %pre leaving dupes behind
[12:41]  <rdieter> scop: I can, and will try it.
[12:41]  <spot> there's a security hole in there somewhere...
[12:42]  <scop> spot, yes, that is noted in the last paragraph
[12:43]  <rdieter> or can yum proceed to the cleanup stage for other non-broken packages in the same transaction?
[12:43]  <rdieter> I thought it (used to anyway) would abort
[12:43]  <scop> if it does, I do see how the trashing could happen
[12:44]  <scop> I also think that would be a pretty severe bug in yum or whatever works that way
[12:44]  <spot> seems to me like this is worth testing before we vote on that draft
[12:44]  <rdieter> ok, then nevermind, it's yum's fault... :)
[12:44]  <scop> ("that way" = aborts)
[12:44]  <rdieter> is that what: yum -t , yum --tolerant is for?
[12:45]  <lutter> rdieter: arether any other options if using %pre doesn't do the right thing ?
[12:46]  <spot> would it be worthwhile to print "User $foo already exists!"
[12:46]  <rdieter> I'm starting to think keeping the proposal as-is is the lesser evil.
[12:46]  <lutter> it seems the nameclash is a problem with creating users from packages, no matter what we do; only choice is how messy it gets
[12:46]  <spot> trap the exit code, print on the conditional, let the user installing it know that the user existed already and that the app may not behave as expected.
[12:47]  <scop> hey, let's add vendor prefixes to user/group names!
[12:47]  * scop ducks
[12:47]  * spot throws his lunch at scop
[12:47]  * scop ducked too early
[12:47]  <rdieter> spot: I thought we're not supposed to spew output in scriptlets?
[12:48]  <spot> We're not supposed to, but this is a special "your baby is about to be eaten by dingos" case.
[12:48]  <lutter> spot: might be worth it, even if in a lot of cases nobody will see it
[12:48]  <rdieter> oh well, that's ok then.
[12:48]  <Kevin_Kofler> Don't forget that there's other depsolvers than yum too. There's apt-rpm, there's smart, and then there's even the case of someone running rpm -Uvh on a bunch of packages manually.
[12:48]  <lutter> scop: what we could do is keep a registry of system accounts across Fedora; that'll at least give admins some sense of whether their favorite user names will cause problems
[12:49]  <scop> lutter, agreed, that's what I mentioned on list too when this was last discussed
[12:49]  --> aalamC has joined this channel (n=aalam@220.224.76.193).
[12:49]  --> inserto has joined this channel (n=Belkin@217.8.236.2).
[12:49]  <spot> I think the registry is a decent idea, it should be integrated as part of the process in the draft
[12:49]  <spot> "1. add user/group to registry 2. do it in the package like this"
[12:50]  <spot> we might even be able to hook the registry into shadow-utils to warn admins
[12:51]  <spot> "Note: this username is reserved by $application"
[12:51]  <lutter> that would be even better
[12:51]  <tibbs> But some packages do have pretty dumb user names.  Like "amanda".
[12:52]  * spot shrugs innocently
[12:52]  <tibbs> For years I had to rebuild that package to use "dumpuser" instead.
[12:53]  <wwoods> 's a backronym. advanced maryland automatic network disk archiver. but yeah, reserving the username "amanda" kinda sucks
[12:53]  <lutter> just keeping something like the uidgid from setup up-to-date that way would be good
[12:53]  <f13> email from 'amanda' makes admin's wives "happy".
[12:53]  <scop> http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroupsThoughts has some registry related ideas
[12:54]  <scop> Provides: user(foo) and friends would be good for querying purposes
[12:54]  * spot would like to see some of that incorporated in the draft
[12:54]  <spot> scop: ++
[12:54]  <spot> oh, thats nice. :)
[12:55]  <rdieter> nice++
[12:55]  <tibbs> I don't see what Provides: user(blah) could hurt, and it might be useful at some point.
[12:55]  <lutter> scop++
[12:55]  <scop> ok, what about the "already exists when package installed" case?
[12:56]  <spot> I think we should trap the error code
[12:56]  <scop> I think spewing the warnings would end up in a *lot* of spewage
[12:56]  <tibbs> It definitely can't throw any error.
[12:56]  <spot> and just print a warning if the user existed
[12:56]  <lutter> how about distinguishing betwen a system account with the same name (probably ok) and a normal user account with the same name (warning/error)
[12:56]  <scop> essentially a warning would be printed on upgrade of every package that installs one!
[12:57]  <spot> scop: thats a valid concern
[12:57]  * spot mumbles about a wish for %{preupdate}
[12:58]  <scop> my concern is that when we get these scripts to do everything everyone wants, it'll take a 50 line shell script to do it
[12:58]  <lutter> yeah, to do spiffy error checking, you'd want that in some standard script, not in every specfile
[12:58]  <tibbs> lutter: It's not possible to distinguish between a normal user account and an account the admin created to fix the user ID.
[12:59]  <spot> as much as i'd like to solve this one, i'm not sure we can. we dont want to spew on upgrades
[12:59]  <lutter> tibbs: not perfectly, no, but you could use some heuristics like uid >= | < 500, same homedir as what the package wants etc.
[12:59]  <spot> how about, if we fail, fallback to a known system user
[12:59]  <spot> like nobody
[12:59]  <lutter> spot: that kills preassigning uid's, too
[12:59]  <tibbs> lutter: That would break on my systems already.
[12:59]  <scop> rpm already falls back to root for stuff in %files
[13:00]  <lutter> tibbs: and I only meant the heuristic to decide whether there should be a warning or we carry on and assume it's ok
[13:00]  <tibbs> I'm not sure what good a warning would do in any case.  People don't actually get to see them.
[13:01]  <-- inserto has left this server ("Leaving").
[13:02]  * rdieter needs to run soon (another meeting).
[13:02]  <abadger1999> spot: How would that work?  Failure to create the user in the %pre would have to edit a config file or even recompile a binary, right?
[13:02]  <-- nim-nim has left this server ("Leaving.").
[13:02]  <scop> ok, action items: I'll add some user registry stuff to the draft, and rdieter provides me with some test cases/results related to %pre trashes-or-not?
[13:02]  <rdieter> scop: can do.
[13:02]  <scop> rdieter, thanks
[13:03]  <spot> abadger1999: i was more thinking "if user creation failed, reset the user variable to something safe and present, then use that in the rest of the spec."
[13:03]  *** rdieter is now known as rdieter_away.
[13:04]  <spot> anyways, i think we're done for the day. any last items?
[13:04]  <scop> none here
[13:04]  <abadger1999> nope
[13:04]  <spot> ok, thanks guys. time for lunch!
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes20070522&oldid=66543"