Packaging:Minutes20070327

From FedoraProject

Revision as of 03:20, 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.03.27}

Present

The entire committee was present:

Writeups

The following draft has been accepted by FESCO and is to be written into the guidelines:

Votes

The following proposals were considered:


Other Discussions

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


IRC Logs 

[11:58]  * spot is here
[11:58]  <tibbs> I'm here.
[11:58]  * sereinity too
[11:59]  <abadger1999> I'm here
[12:01]  * mmcgrath not here
[12:02]  <rdieter> here
[12:02]  <abadger1999> f13, lutter, racor: ping
[12:02]  <spot> so, we're missing lutter, f13, racor, thimm, scop
[12:03]  --> scop has joined this channel (n=scop@cs27014175.pp.htv.fi).
[12:03]  <spot> scop: welcome!
[12:03]  <lutter> spot: I am on the phone, should be done in 10-15 mins
[12:03]  <racor> sorry, i've been distracted ... but due to DST shift am very short on time and will probably have to leave early
[12:04]  <tibbs> Odd, I though the meeting time for Europeans did not change.
[12:04]  <racor> it did last weekend
[12:05]  <abadger1999> k.  We should get started then.
[12:05]  <spot> item 1
[12:06]  <spot> cmake draft was ratified by FESCO
[12:06]  <spot> item 2
[12:06]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/PostRelease
[12:06]  <spot> Post Release Package guidelines
[12:07]  <tibbs> I made some comments on-list.
[12:08]  <scop> this is essentially what it was in the original fedora.us guidelines, and it was met with strong opposition when it got transferred to FE
[12:08]  <tibbs> Which part resulted in strong opposition?
[12:08]  <racor> I am missing %{?dist}
[12:08]  <spot> racor: dist goes on the end
[12:09]  <scop> tibbs, moving the non-numeric part to the release tag
[12:09]  <tibbs> I see no need to specifically mention dist in every section of the guidelines separatelyl.
[12:09]  <racor> then this postrelease won't work
[12:09]  <spot> racor: why not?
[12:09]  <tibbs> I fail to see now it won't work.
[12:09]  <tibbs> It works fine for prereleases where we use the same scheme.
[12:09]  <racor> 1.1.1-1.fc6
[12:10]  <rdieter> spot: looks good to me, I'm all for it.
[12:10]  <racor> post release of release
[12:10]  <racor> post-release or release?
[12:10]  <tibbs> scop: If we can't do that, then we can't use upstream versioning at all if it doesn't sort properly.
[12:10]  <rdieter> 1.1.1-2.GA1.fc6
[12:10]  <spot> 2 > 1
[12:10]  <tibbs> 1.1.1-2.GA1.fc6.1
[12:10]  <scop> tibbs, yes we can, we just bump the epoch in the extremely rare cases where there is a problem
[12:11]  <tibbs> The problem is that there are packages where this isn't an extremely rare case.
[12:11]  <scop> care to mention one by name?
[12:11]  <tibbs> You'd get an epoch bump rather often for those.
[12:11]  <tibbs> Fnasser mentioned at least one on-lis5t.
[12:12]  <tibbs> That was the reason this came up at all.
[12:12]  <spot> i'm not sure we can craft a generic solution to that other than "use epoch"
[12:12]  <rdieter> tibbs: imo, in cases where it's not rare, upstream needs some whacking.
[12:13]  <spot> i'd rather pound on upstream if it becomes a problem
[12:13]  <tibbs> Well, yes, but we know that there are cases where upstream does things on purpose just to screw with us.
[12:13]  <abadger1999> tibbs: Unfortunately true :-(
[12:13]  <f13> eep, I'm here.
[12:13]  <rdieter> exceptions can be dealt with.
[12:14]  <tibbs> If epoch is the answer, then great, we just need to at least mention it somewhere.
[12:14]  <spot> i'd like to get these ground rules in, we can add extra bits later as needed
[12:14]  <tibbs> spot: I think the issue is that scop objects to basically everything you're adding in your draft.
[12:15]  <spot> scop: do you?
[12:15]  <spot> alli saw was that he said it was the same as the old fedora.us guidelines and some people opposed it
[12:15]  <rdieter> and I didn't think "some people" = "scop". :)
[12:16]  <tibbs> So where is the "strong opposition"?
[12:16]  <scop> and I have no desire to be a part of re-igniting those flamewars
[12:16]  <spot> well, we're simply adding another option to the existing guidelines
[12:16]  <spot> we're not mandating that it be used.
[12:16]  <scop> ok, I missed that bit
[12:16]  <tibbs> This is a rule to cover the case of non-sorting upstream versioning.  It seems to me to be a sane enough way of dealing with non-sane upstreams.
[12:17]  <scop> if it's not a must, I won't object
[12:17]  <spot> but if you want the post-release tag in the n-v-r, these are the two ways to do it.
[12:17]  <spot> you don't have to have it at all.
[12:17]  <tibbs> spot: Perhaps add a note that you can use this, or just bump Epoch: when necessary.
[12:17]  <spot> i can add a one-liner for epoch.
[12:18]  <tibbs> I think the point is that there really aren't any other options.
[12:18]  <spot> tibbs: sure there is, don't put the post-release tag in the n-v-r. :)
[12:18]  <spot> can we vote on the draft + epoch line?
[12:18]  <abadger1999> I'd like to see a little tweaking of the wording: "More complicated versions" but I'm okay with the draft otherwise.
[12:18]  <tibbs> If that's a real option then it needs to be listed out as well, I think.
[12:19]  <spot> abadger1999: suggested alternative?
[12:19]  <tibbs> I wasn't aware that it was permitted to deviate from upstream versioning in that manner.
[12:19]  <spot> tibbs: we never said it wasn't.
[12:19]  <abadger1999> Something like: "When upstream tries to use versions that include abbreviations we can run into ordering problems"
[12:20]  <f13> spot: can we chnage ALPHATAG to POSTTAG ?
[12:20]  <scop> versioned self-obsoletes would be another alternative way to handle this, alas IIRC that doesn't work nowadays so it doesn't make sense to promote it
[12:20]  <f13> nit-picky but might save confusion.
[12:20]  <tibbs> So now I'm confused; are packagers under no obligation to follow upstream versioning?
[12:20]  <rdieter> tibbs: you should when you can (and it is sane).
[12:21]  <abadger1999> My wording wasn't that great either, but the essence is to answer the question "How does a novice packager tell when upstream is smoking the crack pipe?"
[12:21]  <rdieter> use of >1 non-numeric in version = crack-pipe
[12:22]  <tibbs> Use of anything besides real numbers = crack pipe.
[12:22]  <spot> ok, i just amended the draft. alphatag is now posttag, changed to abadger's wording, added two lines on epoch.
[12:22]  <tibbs> Hmmm.
[12:22]  * f13 refreshes
[12:23]  <spot> slow wiki, might not have gotten it yet, my browser is still waiting
[12:23]  <tibbs> I see it.
[12:23]  <abadger1999> rdieter: +1
[12:24]  <rdieter> got it, looks good to me.
[12:24]  <f13> I see it.
[12:24]  <f13> looks reasonable to me.
[12:24]  <scop> I would trim the prereleases from the example
[12:24]  <spot> scop: the only reason i left it in there was to make it clear how the whole process works
[12:24]  <spot> in my estimate, if they do post, they do pre too.
[12:24]  <abadger1999> I don't think my wording works quite right either.  For instance 1.0beta 1.0rc 1.0final
[12:25]  <abadger1999> Oops.  That's pre-release, not post release.
[12:25]  <spot> abadger1999: maybe "When upstream uses versions that either have or are likely to have ordering problems"
[12:26]  <abadger1999> "When upstream uses versions that attempt to have meaning to humans instead of being easy for a computer to order"
[12:26]  <spot> ooh, i like that
[12:27]  <abadger1999> "For instance, GA1, CR2, PR3"
[12:27]  <f13> I like that too
[12:27]  <f13> counting starts at 0 damnit!  (:
[12:27]  * rdieter liked "When upstream smokes crack-pipe" better, but oh well? :)
[12:27]  * spot commits that change
[12:27]  <spot> ok guys, lets vote on this draft.
[12:28]  <f13> +1
[12:28]  <tibbs> +1
[12:28]  <spot> +1
[12:28]  <rdieter> +1
[12:28]  <scop> +1
[12:28]  <abadger1999> +1
[12:29]  * spot isn't sure if racor is still here or not
[12:29]  <spot> but the vote passes
[12:29]  <scop> "For instance, GA1, CR2, PR3" -- CR2 and PR3 look like prereleases, not postreleases?
[12:29]  <spot> next item:
[12:29]  <spot> scop: believe it or not, they're post.
[12:29]  <spot> hooray for java crack.
[12:29]  <scop> ooh
[12:29]  <spot> http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros
[12:30]  <spot> Dag pointed this out on epel-list
[12:30]  <tibbs> I like these but I'm concerned that the syntax is even less pleasant than the %if bits.
[12:30]  <lutter> ok .. off the phone
[12:30]  <rdieter> I like it.
[12:30]  <tibbs> And there seems to be a general dislike of more RPM macros from some quarters.
[12:30]  <lutter> me too
[12:30]  <spot> tibbs: it seems pretty clean to me.
[12:31]  <rdieter> tiibs: then "those quarters" shouldn't use them.
[12:31]  * spot points out that all of these macros are optional
[12:31]  <lutter> tibbs: and we use %{?macro: ...} in quite a few otehr places
[12:31]  <spot> they're there if you want/need em
[12:31]  <tibbs> Does it work for multiline bits?
[12:31]  <scop> those macros are not available to people who rpmbuild --rebuild locally
[12:32]  <scop> if the packager has chosen to use those "optional" macros, the build will most likely be screwed
[12:32]  <rdieter> scop: mock, mock, baby.
[12:32]  <tibbs> I.e. can the "a", "b", etc. in the examples be multiline?
[12:32]  <spot> tibbs: i think so, but i'm not 100% sure there
[12:32]  <f13> scop: likewise if they depend on the existing %{fedora} or %{rhel} macros
[12:32]  <spot> they could always do:
[12:32]  <spot> %if "%el5"
[12:32]  <f13> or rely on something in %{?dist}
[12:33]  <spot> instead of %if "%rhel" == "5"
[12:33]  <scop> f13 yes, which is why I think it's a bad idea to use any of those macros
[12:33]  <f13> I don't think it's bad, I think they should be used with care.
[12:33]  <racor> spot: consider me gone, I can't follow today's meeting in reasonalbe manners. This time-slot isn't working for me :(
[12:33]  <rdieter> speaking of "local" builds (like scop's comment), why not put buildsys-macros in the main repo?
[12:33]  <f13> I really think we should start shipping buildsys-macros in say fedora-release though
[12:34]  <spot> racor: sorry. :(
[12:34]  <f13> so that these things WILL get resolved locally and they can override if need be (or use mock)
[12:34]  <spot> rdieter: +1
[12:34]  <rdieter> f13: :)
[12:34]  <f13> I know jeremy has had concerns with this possibly "surprising" people, but really I think they'd be more surprised if these macros /didn't/ resolve.
[12:35]  <spot> no macros are changing. we're just adding some new ones.
[12:35]  <spot> and we'll announce the change.
[12:35]  <scop> include the macros in redhat-rpm-config instead
[12:35]  <tibbs> So do we have buy-in from the maintainer of whatever package will contain these?  And what releases will be covered?
[12:35]  <spot> tibbs: fedora and rhel
[12:35]  <f13> who owns buildsys-macros?
[12:36]  <rdieter> I'd rather these continue to be packaged separately, but they get Require:'d by fedora-release or redhat-rpm-config.
[12:36]  <rdieter> I don't think anyone officially owns it (yet), who owns mock?
[12:36]  <-- giallu has left this server (Read error: 110 (Connection timed out)).
[12:36]  <spot> f13: dgregor
[12:36]  <tibbs> spot: The examples cover el2, though; surely we can't get updates going that far back.
[12:37]  <f13> spot: he owns that in Extras?  weird.
[12:37]  <spot> f13: oh, extras?
[12:37]  <f13> yeah
[12:37]  <scop> sure, pulling them in through a dependency in redhat-rpm-config would work as well
[12:37]  <spot> f13: i dont think its in FE
[12:38]  <spot> tibbs: the DistTag document mentions .el2
[12:38]  <f13> spot: how is it populating the Extras buildroots with these macros?
[12:38]  <lutter> afaik, they are just floating around out there, like on buildsys.fp.org
[12:38]  <rdieter> perhaps someone on FPC could/should own it?
[12:38]  <f13> interesting.
[12:38]  <f13> I can own them.
[12:38]  <f13> I own them internally or at least make the changes to them.
[12:38]  <spot> yeah, i think you should own them. :)
[12:38]  --> thimm has joined this channel (n=thimm@p54BD5D7C.dip.t-dialin.net).
[12:38]  <tibbs> spot: I'm not sure how that's relevant, though.  The example will never actually work, will it?
[12:39]  <spot> tibbs: not for any case we care about
[12:39]  * thimm is sorry, I couldn't make it in time :/
[12:39]  <spot> tibbs: but for dag, he might be using them somewhere else.
[12:39]  <spot> and there is really no reason EPEL couldn't support RHEL 2.1 someday
[12:39]  <spot> if they were feeling horribly masochistic.
[12:39]  <lutter> for general sanity, would probably be good if buildsys-macros was in fc proper
[12:40]  <f13> yeah, I want to run the idea again of having it available in the repo
[12:40]  <spot> f13: you look into owning it and making it get pulled in by redhat-rpm-config ?
[12:41]  <f13> yeah
[12:41]  <spot> ok. lets vote on the draft, with the knowledge that we're working on the buildsys-macros package issue
[12:41]  <f13> +1
[12:41]  <spot> +1
[12:41]  <thimm> URL?
[12:41]  <rdieter> +1
[12:41]  <scop> http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros
[12:42]  <tibbs> +1 although I do object to including an example that we don't intend to make work.
[12:42]  <thimm> Thanks, +1
[12:42]  <thimm> tibbs: which example?
[12:42]  <spot> thimm: el2
[12:42]  <f13> why wouldn't we make it work within EPEL?
[12:42]  <lutter> +1
[12:43]  <f13> we can populate the buildroots with whatever we want
[12:43]  <spot> abadger1999: would you like to vote? :)
[12:43]  <f13> %{?dist} tag was functional in Extras long before I enabled it in Core / RHEL
[12:43]  <tibbs> We actually have an el2 buildroot?
[12:43]  <thimm> Suggestion: Please add a comment that we actually discourage using these if features are being probed
[12:43]  <abadger1999> +1 if we get the macros into the distro.
[12:44]  <spot> thimm: seems reasonable.
[12:44]  <rdieter> thimm: define "feature probing"?
[12:44]  <thimm> Otherwise people would not prope for say selinux
[12:44]  <thimm> probe
[12:44]  <f13> tibbs: we don't as there isn't any demand.  Should there be demand, we just might do el2 buildroots.
[12:45]  <thimm> f13: demand for RHEL3 is already 1/20th of RHEL4
[12:45]  <thimm> So for RHEL2.1 it will be even smaller I guess
[12:45]  <spot> ok, the draft passes
[12:45]  <rdieter> point is, *we* shouldn't rule it out as a possibility.
[12:45]  <thimm> no, but we don't, do we?
[12:45]  <spot> next item: ruby gems
[12:46]  <spot> lutter: do you have anything new this week?
[12:46]  <lutter> spot: no, sorrry, didn't haevb time last week to look into the rubygems stuff we discussed
[12:46]  <spot> ok. we'll put that aside.
[12:46]  <lutter> hopefully next week
[12:46]  <spot> next item: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
[12:47]  <spot> scop: is this ready to be looked at?
[12:47]  <scop> no
[12:47]  <spot> ok. we'll move on.
[12:47]  <scop> there's a "---" in the middle of the doc, stuff after that was added by Enrico
[12:47]  <tibbs> Should we talk about the fact that we're now to make policy for EPEL as well?
[12:48]  <scop> I haven't dug into it, but I have a feeling I don't personally agree with it
[12:48]  <spot> tibbs: i mentioned that last week
[12:48]  <spot> i'm pretty sure i did.
[12:48]  <thimm> spot: you did
[12:48]  <tibbs> Perhaps, but I don't recall discussing any changes we will have to make because of it.
[12:48]  <tibbs> For example, are all of our current guidelines appropriate for EPEL?
[12:48]  <thimm> We'll have to find out on the way I guess
[12:49]  <tibbs> Do we need to make a review of them?
[12:49]  <spot> no one has said that they aren't.
[12:49]  <thimm> I think the idea is to have EPEL ping us when something is wrong for EPEL
[12:49]  <f13> I'm sure many of our package specific macros don't work with RHEL4's rpm
[12:49]  <thimm> I'll package a helper package for that
[12:49]  <f13> and things like kmods may not work well at all.
[12:49]  * thl wonders if we need the explicit "python(abi)" stuff abck for EPEL < 5
[12:49]  <spot> f13: now now, no need to curse.
[12:50]  <f13> thimm: some of it is the rpm version itself, not just missing macros.
[12:50]  <f13> thimm: certain conditionals are not usable by RHEL4's rpm
[12:50]  <thimm> f13: which ones?
[12:50]  <rdieter> thl: yes, explicit python(abi) is/would-be required for epel < 5.
[12:50]  <f13> I can't remember which, I just noticed it came up a month or so back internally
[12:50]  <scop> %bcond_*
[12:50]  <thimm> That's a macro, f13 means something else
[12:51]  <thimm> f13: Could you dig it up and PM me? Thanks!
[12:51]  <scop> well, that's a conditional too, and not usable by RHEL4's rpmbuild :)
[12:51]  <f13> thimm: that may have been it.
[12:51]  <spot> ok, so there are a few items on the todo list that need some work
[12:51]  <thimm> scop: I will create a "fedora-compatibility-rpm-macro-package" for EPEL :)
[12:51]  <thl> rdieter, then I'd say we should add it back somewhere somehow; even I forgot how it works exactly...
[12:52]  <rdieter> thl: I think the python page still references it (somewhere).
[12:52]  <spot> specifically, i'm looking at arch specific script packages, user/group handling, cross compilations, license tags
[12:52]  <spot> if you own one of these (f13, rdieter, tibbs, scop)
[12:52]  <spot> well, not rdieter. sorry. ;)
[12:53]  * rdieter though he was getting drafted there for a minute.
[12:53]  <tibbs> I shouldn't be on cross-compilation any longer.
[12:53]  <spot> please either clean it up for consideration or pull it off the todo list
[12:53]  <tibbs> spot: I know you have something else going on with regards to licenses.
[12:53]  <spot> yeah, feel free to drop that item entirely for now
[12:54]  <rdieter> I'll pull the iconcache proposal from ToDo, since it is indefinitely tabled (someday maybe)
[12:54]  <thimm> Why?
[12:54]  <thimm> Weren't we about to approve it?
[12:54]  <scop> I'll try to beat UsersAndGroups into a discussion draft shape for next week's meeting
[12:54]  <spot> scop: you may want to run it past notting via email
[12:54]  <rdieter> thimm: talking to me?
[12:54]  <tibbs> spot: If you want to work on licenses, I'm game, but I'd like to know what you have planned at some point.
[12:55]  <spot> scop: he had a lot of thoughts on that
[12:55]  <scop> spot, ok, will do
[12:55]  <thimm> rdieter: yes, about iconchache
[12:55]  <spot> tibbs: no problem.
[12:55]  <f13> spot: hrm, I still have no good solution for the arch specific noarch script stuff.  :/
[12:55]  <scop> (and now, after having a look at stuff people have added to the current draft, a lot of those make perfect sense)
[12:55]  <f13> I think it requires changes to rpm, and well...
[12:56]  <abadger1999> If we're out of items to discuss, we could look at this: http://fedoraproject.org/wiki/PackagingDrafts/Utf8Filenames
[12:56]  <rdieter> thimm: well, icon_cache is still a volatile subject to some, maybe giving it some time can garner a little more consensus.
[12:57]  <thimm> rdieter: Is anyone of the FPC volatile?
[12:57]  <thimm> I thought that "only" some package maintainers were against it
[12:57]  <rdieter> thimm:   f13 (by proxy) :)
[12:57]  <scop> utf8filenames: what's "convmv"? ASCII is UTF-8 compatible, so plain "Filenames must be encoded as utf8" suffices
[12:58]  <thimm> rdieter: But the proxy only promised to fix that in the far future
[12:58]  <tibbs> It's more of an issue that we can't use packaging guidelines to force Gnome to do anything.
[12:58]  <spot> utf8filenames seems ok to me.
[12:58]  <tibbs> I agree with utf8filenames.
[12:58]  <f13> I just continue to get pushback on enforcing any packaging guideline if we don't take their concerns into consideration and just force things down their throat. :/
[12:58]  <f13> +1 to utf8
[12:59]  <spot> +1 to utf8
[12:59]  <rdieter> tibbs: it's more of gnome forcing everyone else to use gtk-update-icon-cache. :)  But we've been down that road...
[12:59]  <lutter> +1 for utf8
[12:59]  <abadger1999> +1 utf8
[12:59]  <rdieter> +1 utf8.
[12:59]  <tibbs> +1 utf8.
[12:59]  <abadger1999> scop: convmv is a program that can rename files from one encoding to another.
[13:00]  <scop> needs a BuildRequires?
[13:00]  <tibbs> What package is it in?
[13:00]  <rdieter> f13 has a point about pushback, I'm willing to let the topic/issue simmer for awhile.
[13:00]  *** thl is now known as thl_afk.
[13:00]  <tibbs> Ah, the convmv package.
[13:01]  <tibbs> Does rpmlint complain about non-utf8 filenames?
[13:01]  <f13> if it, we can make it do so easily
[13:01]  <f13> and if we pass this we should.
[13:01]  <scop> s/use convmv in your %install/can use for example convmv in your %install/
[13:01]  <f13> actually, that brings up a good point.
[13:01]  <f13> one step in adding any new rule should be "can rpmlint check for this" and helping to create an rpmlint check if possible.
[13:01]  <spot> yes, rpmlint seems to.
[13:02]  <tibbs> What about the contrapositive?  "If it's not in the guidelines, rpmlint shouldn't complain about it."
[13:02]  <spot>                         if use_utf8 and not is_utf8(path):
[13:02]  <spot>                             printWarning(pkg, 'file-not-utf8', f)
[13:02]  <thimm> utf8-voting: -1
[13:02]  <thimm> Sorry
[13:02]  <scop> spot, that's for file contents
[13:02]  <thimm> +1
[13:02]  <spot> scop: ah, ok.
[13:02]  <scop> but bleeding edge svn rpmlint checks file names too: http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1327
[13:02]  <f13> tibbs: erm... I'm not exactly comfortable with that.
[13:03]  <abadger1999> scop: Changed to " If upstream ships filenames that are not encoded in utf8 you can use a utility like convmv (from the convmv package) to convert the filename in your %install section.
[13:03]  <abadger1999> "
[13:03]  <tibbs> f13: Perhaps not, but it's an interesting question.  "mixed spaces and tabs", is a good example.
[13:03]  <scop> abadger1999, better, +1
[13:04]  <spot> ok, utf8 passes
[13:04]  <scop> abadger1999, or just "mv", eg. mv Skytt? Skyttä
[13:04]  <tibbs> Need EPEL branches and maintainer for convmv, I guess.
[13:04]  <f13> tibbs: sure.  I'm fine with objecting to specific rpmlint tests and adding it to a fedora specific filter.
[13:05]  <thimm> scop: Seems nice and KISS
[13:05]  <thimm> But rpmlint will probably thing specfile is non-utf8 ;)
[13:05]  <scop> no, the "?" is a literal question mark
[13:06]  <thimm> ah, OK :)
[13:06]  <spot> ok guys, any other issues? or are we done?
[13:06]  * spot has lots and lots to do today, so... ;)
[13:06]  <rdieter> done: +1
[13:07]  <spot> thanks all.
[13:07]  <thimm> spot working +1
[13:07]  <thimm> ;)
[13:07]  <thimm> bye all
[13:07]  <tibbs> I'll write up the minutes.
[13:07]  <abadger1999> Thanks tibbs
[13:07]  <tibbs> If anyone has any comments on the format, please let me know.
[13:07]  <abadger1999> scop: Hmm... I wonder how that works with multibyte characters.
[13:08]  <scop> nothing urgent, but food for thought: I came across PLD hardlinking *.pyc and *.pyo in binary packages whenever they're identical, and they are in a lot of cases
[13:08]  <scop> abadger1999, use * then :)
[13:08]  <f13> scop: I wonder how much space that saves
[13:09]  <abadger1999> scop: :-)
[13:09]  <scop> f13, not much in *.rpm sizes (surprisingly?) but of course some when installed
[13:09]  <tibbs> Something could run through and do that automatically for any identical files in a package.
[13:09]  <scop> yes, OTOH taking possible filesystem boundaries into account
[13:10]  <tibbs> Unfortunately that would restrict it to files in the same directory.  Or rpm needs to be able to break those links at install time.
[13:10]  <scop> yep
[13:10]  <scop> but in the *.pyc, *.pyo case, they are in the same dir
[13:10]  <scop> $ /usr/sbin/hardlink -nvc /usr/lib64/python2.4 2>&1 | tail -n 1
[13:10]  <scop> Would save 9859072
[13:11]  <tibbs> Unfortunately don't forget that rpmbuild compiles the files itself.  We have no hook to get in after that process, so rpmbuild would have to do the hardlinking itself.
[13:12]  <scop> yes, that could be done in the very same hook that compiles the files
[13:12]  <scop> (and should be done there, if it's seen something worth adopting in the first place)
[13:13]  <tibbs> Anything to save space, sure.
[13:14]  <tibbs> But I guess it's a discussion for the rpm maintainer.  (Or is that the python maintainer?)
[13:14]  <tibbs> brp-python-bytecompile is in rpm-build.
[13:15]  <spot> scop: draft it? :)
[13:17]  <scop> I'll post to fedora-devel sometime for discussion first
[13:18]  <scop> anyway I found it somewhat odd that it didn't save practically any space in *.rpm files
[13:18]  <scop> perhaps rpmbuild already does something like hardlinking internally when it composes the payload
[13:19]  <tibbs> Or the regular compression is taking care of it.
[13:21]  <-- thimm has left this channel.
[13:22]  <f13> would we lose out any functionality by making them hardlinks?
[13:22]  <f13> we _do_ care a lot about the size of the stuff once installed, for things like LiveCD and OLPC
[13:22]  <tibbs> I can't imagine how it could make any difference.  The system will just break the link if for some reason one of them gets modified.
[13:29]  <f13> tibbs: just covering the bases.
Retrieved from "https://fedoraproject.org/wiki/Packaging:Minutes20070327"