From Fedora Project Wiki

Fedora Packaging Committee Meeting - 2008-10-21

Present

  • DenisLeroy (delero)
  • JasonTibbitts (ubertibbs)
  • RalfCorsepius (racor)
  • RexDieter (rdieter)
  • TomCallaway (spot)
  • ToshioKuratomi (abadger1999)

Submitted for FESCo approval

The following proposals were considered:

Other Discussions

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

  • New guideline relating to generically named packages and files.
    • Tough to actually write a guideline involving the use of common sense as applied to things like this.
    • Jason will draft a proposal for consideration soon.

IRC Logs

* spot looks around 12:05
spot abadger1999, tibbs|h, rdieter, around? 12:06
--> racor has joined this channel (n=rc040203@HSI-KBW-078-043-056-093.hsi4.kabel-badenwuerttemberg.de). 12:06
rdieter yo 12:06
abadger1999 spot: here. 12:06
spot SmootherFrOgZ: ping? 12:06
abadger1999 busy busy though :-(... haven't had time to update javascript guidelines. 12:07
racor half here (networking probs) 12:07
spot i don't see Rathann online 12:07
--> delero has joined this channel (n=denis@nat/sun/x-9fcfcfad87b03708). 12:07
* delero is here 12:08
spot okay, so i count 5 12:08
spot (well, 4 and a half... ;) 12:08
ubertibbs I'm here. 12:09
spot ahh, okay 12:09
ubertibbs Sorry, you pinged me at home. 12:09
spot i wasn't expecting ubertibbs. ;) 12:09
ubertibbs Silent protest. 12:09
delero lol at tibbs 12:09
abadger1999 :-) 12:09
spot okay, lets get this first one out of the way 12:10
spot Andrew Overholt sent over a diff for updating the Eclipse guidelines 12:10
spot "Updates to Eclipse Plugin packaging guidelines" 12:10
ubertibbs I was +1 on list. 12:11
spot i was also +1 on list 12:11
delero same here, although the path "/usr/lib{64}/.../buildscripts/" is somewhat offensive :-) 12:11
spot so was delero 12:11
spot i can only assume the buildscripts became arch dependent 12:12
delero right, considering that this is eclipse, it makes sense 12:12
rdieter +1 updates 12:13
abadger1999 +1 12:14
spot okay, thats a +5, racor, would you like to vote on the record? 12:14
spot okay, i will assume he is still having networking issues 12:15
spot next item is new, so please read it: https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor 12:15
racor +1 12:15
ubertibbs Oh, goody. 12:15
abadger1999 +1 12:16
rdieter +1 12:16
spot +1 from me as well (i usually don't vote against my own drafts) 12:16
abadger1999 spot: Do you also want to ping mclassen about migrating old .desktop files? 12:16
rdieter fwiw, mclasen supports it. 12:17
spot abadger1999: well, i don't think we can or else we'll break menu-editing, won't we? 12:17
abadger1999 Immaterial to this vote but I'd like to see this go away altogether. 12:17
delero +1 from me 12:17
ubertibbs +1 12:17
spot note the last line in the draft 12:17
abadger1999 spot: Last time this was brought up, mclassen was going to work on the menu-editing/customizing issue. 12:18
abadger1999 He made some progress but we never heard that it was finished. 12:18
rdieter menus that included customized items where vendors change results in menus with orphaned items. 12:18
abadger1999 Or what the scope of the "fixes" were. 12:18
spot okay, so i say we should leave it as i've drafted it, and when mclasen works on the menu-editing/customization issue, we consider dropping it across the board 12:18
spot s/mclasen/anyone 12:19
abadger1999 Definitely. 12:19
spot racor: we're at +5, but as always, i'd like to have your vote on the record 12:19
rdieter shrug, is it worth fiddling with the definition of "life of a package"? I mean, modifying vendor between f9->f10 could arguably be acceptable. 12:20
ubertibbs I'd argue not. 12:20
<-- racor has left this server (Remote closed the connection). 12:20
abadger1999 rdieter: Let's see if mclassen has come up with something first. Then we'll know how much will break. 12:20
spot abadger1999: can you and rdieter follow up with mclasen? 12:21
--> racor has joined this channel (n=rc040203@HSI-KBW-078-043-056-093.hsi4.kabel-badenwuerttemberg.de). 12:21
rdieter ok 12:21
spot alright. next item: https://fedoraproject.org/wiki/PackagingDrafts/CmakeCpack 12:21
spot this is an addendum to: http://fedoraproject.org/wiki/Packaging/cmake 12:22
ubertibbs I'm afraid I don't really understand the draft. 12:22
ubertibbs Where am I supposed to "use following command"? 12:23
ubertibbs Also, needs editing for grammar. 12:23
spot yeah, grammar fixups i can do 12:23
delero commands go to CMakeLists.txt I suppose 12:23
abadger1999 So this draft leaves me asking... what is this? 12:24
abadger1999 Is this something like "make dist" in autotools and "setup.py sdist" in python? 12:24
rdieter I'm not sure, but we don't want fedora packagers to use Cpack *at all*, do we? (as I understand it, it's a quick-n-dirty way to generate rpms outside of the usual/classic rpmbuild) 12:24
abadger1999 How does it apply to packagers? 12:24
spot i think so. 12:24
ubertibbs It sounds as if this is something that developers would use when generating cpack files, not something Fedora packagers would need to care about. 12:24
spot yeah, i think this isn't something for the packaging guidelines 12:25
delero more for a more general "CMake FAQ' page ? 12:25
racor i don't understand why this should be part of the FPG, internal implementation details I'd say 12:25
spot delero: i'm not even sure about that. CPack seems to be a way to generate a tarball full of binaries. 12:25
spot http://dingyichen.livejournal.com/6905.html seems to have a bit more explanation 12:26
abadger1999 Maybe this could go on the distributions wiki -- I know Debian has a "How upstreams can be friendly to packagers" and that would be good for distributions wiki to have. 12:27
ubertibbs "tarball full of binaries" == "tarball full of fail" 12:27
<-- racor has left this server (Remote closed the connection). 12:27
delero uberfail ? 12:27
spot okay, i don't think we have anyone backing this. 12:27
spot lets move on 12:27
spot https://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction_(fontconfig) 12:28
--> racor has joined this channel (n=rc040203@HSI-KBW-078-043-056-093.hsi4.kabel-badenwuerttemberg.de). 12:28
spot basically, that draft proposes that Fedora start using the conf.avail/ hierarchy in addition to the conf.d hierarchy for fontconfig 12:28
spot this matches fontconfig upstream, so i'm inclined to +1 it 12:30
rdieter make sense, rubber stamp +1 12:30
abadger1999 +1 12:31
spot delero, ubertibbs, racor? 12:31
abadger1999 nim-nim has been a good driver of fonts packaging 12:31
delero +1 from me, looks good 12:31
nim-nim abadger1999: thanks 12:32
racor is conf.avail going to replace conf.d? what's the difference? 12:32
nim-nim the only thing that needs to be decided is if we want to use conf.avail like upstream or FHS-ize it before fedora adoption 12:32
nim-nim racor: upstream puts config snippets in a directory (they call conf.avail) 12:33
nim-nim racor: to activate it they're symlinked in conf.d 12:33
nim-nim so conf.avail is just a repository of config templates 12:33
ubertibbs Which brings up the first comment at the bottom. 12:34
ubertibbs Since they're not actual configuration files. 12:34
ubertibbs But it's probably too late to fix this properly for F-10. 12:34
nim-nim ubertibbs: quite honestly, it's too late to change any font package for F10 12:34
nim-nim so the guideline if it's adopted will be for F11 and later IMHO 12:35
ubertibbs Then can we do it right? I think there's a general push to get non-config stuff out of /etc. 12:35
nim-nim I just want to be 100% that if we go conf.avail like upstream 12:35
nim-nim no one will ask to move the files later 12:35
racor nim-nim: thanks for explaining, then +1, FHS is irrelevant, here 12:35
spot are these really non-config ? 12:35
nim-nim spot: they're config 12:36
nim-nim but read-only 12:36
nim-nim not modifiable 12:36
delero read-only config != config 12:36
nim-nim they're %config without noreplace in our fontconfig package 12:36
ubertibbs That... doesn't make much sense to me. 12:36
nim-nim which means if we decide to go conf.avail rpmlint will complain of every package that applies the guideline 12:37
spot i think if we move to /usr/share without upstream's support, we're going to just make lots of people confused and unhappy 12:37
racor delero: cf. /etc/init.d, /etc/rc.d etc. it does make sense. 12:37
spot since we can always change this later if upstream decides to go to /usr/share, i say lets go with this now 12:37
racor spot: agreed 12:37
spot i count a +5 on this one, ubertibbs, want to vote? :) 12:38
nim-nim spot: the rpm pattern will be spread in many packages then 12:38
ubertibbs We need to collect a list of these "non config in /etc" locations and use it to quiet rpmlint. 12:38
nim-nim lots of pain 12:38
spot nim-nim: can you macroize it? 12:38
nim-nim spot: I could define a set of macro names for default font directories 12:39
nim-nim that would still make a change require a mass rebuilt 12:39
spot well, we're likely to have at least one mass rebuild in the F11 cycle anyways 12:39
abadger1999 gconf, fonts.avail, init.d 12:40
nim-nim (not counting that rpm is not very good at handling symlink changes) 12:40
nim-nim anyway I feel something in /usr/share would be cleaner 12:40
nim-nim but I don't care about it much 12:40
ubertibbs I'm of the same mind. 12:41
spot nim-nim: feel free to try to sell it to upstream, i wouldn't be opposed to it. 12:41
nim-nim I do care about not having to change again lots of font packages later 12:41
ubertibbs But these thing do confuse people at package review time, because rpmlint complains. 12:41
racor nim-nim: no, /usr/share would suffer from the /usr on separate filesystem problem. 12:41
nim-nim racor: do we need fontconfig before /usr on separate filesystem problem is mounted? 12:42
ubertibbs Aren't the actual fonts stored in /usr/share in any case? 12:42
nim-nim ubertibbs: right :p 12:43
racor nim-nim: unless fontconfig is going to support non-X11, then no. 12:43
spot so, thats all i had for today's agenda 12:44
nim-nim racor: I think if we start to use fontconfig early we'll just copy the default font and a minimal config somewhere in /etc anyway 12:44
spot if anyone else wants to raise an item, now would be the time. :) 12:44
ubertibbs Crap, what was it I wanted to ask... 12:44
abadger1999 I'd like to mention that upstream python is discussing the sad state of distutils and setuptools. 12:45
ubertibbs Oh, do we need a guideline covering generically named executables and headers and such? 12:45
nim-nim so I move along with the draft? ask upstream to consider a location in /usr/share ? ask rpmlint to consider whitelisting conf.avail ? prepare a set of rpm macros ??? 12:45
racor sorry, as usual, I got to quit early :( 12:46
<-- racor has left this server ("Leaving"). 12:46
nim-nim just want to be clear on the actions my side 12:46
abadger1999 If anyone cares about python packaging and has the patience to wade through hours of email, the discussion is happening on the distutils-sig mailing list. 12:46
rdieter ouchie 12:46
abadger1999 Right now, it could be really bad for us in the future or really good. I can give a summary after the rest of this meeting is over. 12:47
spot nim-nim: we've approved the draft. 12:47
abadger1999 nim-nim: I think we've voted approved on this... what do you want to do? 12:47
spot if you think /usr/share is a good idea, you should talk to upstream. 12:47
nim-nim ok 12:47
nim-nim so I'll consider 12:47
spot whitelisting in rpmlint seems like a good thing too, you should talk to ville 12:47
nim-nim 1. changing a guideline to use a conf template dir like upstream is approved 12:48
nim-nim 2. actual dir location is pending on discussion with upstream 12:48
nim-nim 3. if upstream want to keep it in /etc => talk with ville on rpmlint whitelisting 12:49
spot sure. we can sit on this until you hear back from upstream. 12:49
nim-nim spot: thank you 12:49
nim-nim spot: I just need for it to be ready when F11 cycle starts 12:49
ubertibbs So, generic executable and header names? 12:50
spot ubertibbs: so, just as a note, we don't need to send that one to FESCo yet, until nim-nim gets back to us on what the upstream location should be 12:50
ubertibbs Sure. 12:50
spot ubertibbs: we could probably use a draft there. it will be a fun one to write, i'm sure. 12:50
ubertibbs I was reviewing a package and pointed out that "/usr/bin/generate" and "/usr/include/defs.h" are a bit too generic and received grumbling that there's nothing in the guidelines about it. 12:51
ubertibbs But I have no idea how to actually specify "too generic". 12:51
abadger1999 It's somewhat implied by the Conflicts Guideline but if someone wants to grumble they won't see it that way. 12:51
ubertibbs Well, that implies that there's an actual conflict, rather than a "possible conflict in the future". 12:52
abadger1999 Right. 12:52
ubertibbs The fact that we have no package providing /usr/include/defs.h currently means that something has gone right so far. 12:52
ubertibbs And I dislike the idea that the first package in gets to keep the name and everything else gets to rename. 12:52
rdieter it's not first-come, first serve. 12:53
abadger1999 +1 12:53
rdieter they'd *both* need fixing at that point 12:53
ubertibbs Well, consider the recent example of arping. 12:53
abadger1999 esp. b/c if there's different distros making different decisions.... 12:53
ubertibbs arping is a long-standing executable out of iputils. Should it rename simply because someone has now written another standalone arping? 12:54
ubertibbs "Consult the packaging committee on a case-by-case basis" is the best I can do, but I don't know if we want to deal with that kind of thing. 12:55
rdieter steel cage death match, winner decides. 12:55
ubertibbs Which I guess is a general question: do we want to deal with that kind of thing? 12:55
rdieter ubertibbs: it's a large judgement call, I suspect fpc consultation in cases of dispute it probably the only way (with usual escalation to FESCo when/if needed). 12:56
abadger1999 <nod> 12:57
rdieter it's hard to codify: don't be stupid 12:57
ubertibbs "Please be cognizant of the potential for conflicts and avoid if at all possible overly generic names. If in doubt, consult FPC before importing any package that is likely to cause conflicts for future packages." 12:58
abadger1999 +1 12:59
spot Sure, i could go with that. +1 13:00
abadger1999 If we get innundated we'll be forced to work on something better. 13:00
ubertibbs OK, I'll write up a draft and propose it to the list. 13:00
abadger1999 So the python thing: Everybody hates setuptools but many people use it because it's the best thing going for python developers to be able to build cross-platform tools right now. 13:03
abadger1999 There's talk of replacing it upstream with a better library. 13:03
ubertibbs Which library might that be? 13:04
abadger1999 upstream developers and distro packagers (mainly Debian people and I) are talking about things on the distutils-sig@python.org list. 13:04
abadger1999 python-setuptools 13:04
ubertibbs I mean which is the better one they want to replace it with? 13:04
abadger1999 Err... python-seutptools is what's being replaced... no name for a new library yet. 13:04
abadger1999 And no code. 13:04
ubertibbs Oh, I thought there was an alternative already out there. Didn't I review part of it? 13:05
abadger1999 well... setuptools has 5-10 different functions. 13:05
abadger1999 I know you reviewed paver which is one replacement for the build function. 13:06
ubertibbs Ah, OK. 13:06
ubertibbs That's what I'm thinking of. 13:06
abadger1999 There's also the installation of non-distro packages. 13:06
abadger1999 And the metadata for the package. 13:06
abadger1999 And library versioning. 13:06
abadger1999 The batle I'm fighting right now is FHS compliance for data files when installed. 13:07
abadger1999 Windows and MacOS encourage developers to install everything in their own directory. 13:08
abadger1999 Whereas FHS wants to spread out into different directories. 13:08
abadger1999 The python-setuptools author has proposed that we mark what kind of files declaratively in the metadata (good). and then someone has to write an install tool that will install the files in the proper places per platform. 13:09
abadger1999 In order for the code to find the files (say locale files or icons or config files) he's proposing to use symlinks. 13:09
ubertibbs Ugh. 13:10
abadger1999 ie the code looks in /usr/lib/python2.5/site-packages/foo/locale/en_US/messages.mo 13:10
ubertibbs I think that would be fail. 13:10
abadger1999 And the install tool has made that a symlink to /usr/share/locale/en_US/LC_MESSAGES/messages.mo 13:10
abadger1999 I've proposed using an API instead. 13:11
abadger1999 People aren't too enthused about either one ATM. 13:11
abadger1999 So if you want to follow along: http://www.python.org/community/sigs/current/distutils-sig/list/ 13:12
abadger1999 If you just have ideas about why symlinks suck and want me to pass them along, I will. 13:12
spot so... i think i can call the FPC meeting at this point. :) 13:14
ubertibbs +1 13:15
spot thanks all 13:15
ubertibbs I don't think I can contribute usefully to the python issues. 13:15
Retrieved from "https://fedoraproject.org/w/index.php?title=Packaging:Minutes/20081021&oldid=66515"