Packaging:Minutes20070522

Present

 * DavidLutterkort
 * JasonTibbitts
 * JesseKeating
 * RalfCorsepius
 * RexDieter
 * TomCallaway
 * ToshioKuratomi
 * VilleSkyttä

Writeups
No meeting last week, so no writeups this week.

Votes
The following proposals were considered:


 * Tweaks to static library packaging guidelines: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges
 * Accepted (7-0)
 * Voting for: racor spot tibbs rdieter abadger1999 scop lutter
 * Voting against: (none)

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


 * Emacs packaging guidelines; will probably be considered next week: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns
 * Guidelines for packages needing users and groups: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
 * OCaml guidelines; draft not yet ready for a vote: http://fedoraproject.org/wiki/PackagingDrafts/OCaml

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