David Nielsen wrote:
2008/4/10, Toshio Kuratomi <a.badger@xxxxxxxxx <mailto:a.badger@xxxxxxxxx>>: David Nielsen wrote: I'll just comment on the ones I own: .. _banshee: Boo.dll files are in an Extras/Boo directory. May be able to disable at buildtime. Note in spec that Boo does not build on ppc Actually Nant does not build on ppc (well 0.86-beta 1 does but look what happened when we tried that), no Nant means no ppc for Boo. Regardless when Banshee 1.0 can be rolled out this should not be an issue anymore as one of the goals as been to remove all those bundled wonders. I am inclined to think the best option is waiting and letting the problem solve itself upstream. Upstream is very friendly and on a mission to destroy these anyways. I'm definitely okay with this for libraries which are simply bundled (ie: the package is shipping the source for an external library and is compiling that before installing it.) It makes sense that we wait for an active and friendly upstream to complete changes they've already planned to do something we want. This appears to be the case for the sources in banshee-0.13.2/ext and some of the libraries in banshee-0.13.2/src/Extras. In the Boo case, though, there's a set of precompiled Boo libraries in banshee-0.13.2/src/Extras/Boo/ which are not accompanied by any source. This is more problematic as we have no way to audit those precompiled bits. Are they Boo? Are they a trojaned Boo? Are they secret government plans to bring about Armageddon masquerading as a .dll? Unless you can read CIL byte code, there's no way of knowing. Here good sir, a tinfoil hat to complete your attire.
Let me ask you this, then, why do we have:: http://fedoraproject.org/wiki/Packaging/Guidelines#SourceRequirementExceptionsat all then? Please give the Packaging Committee a draft with rationale for removing that. After all, if it is overly paranoid to apply thatto mono packages it is overly paranoid to apply that rule to any package.
The source tree for Banshee-1 (current SVN) the only interesting Banshee as it is the only one being worked on, contains no precompiled bundles what so ever. Even the banshee in F9 uses system libraries, except boo on account of nant not allowing us boo on ppc. But the focus should be on getting 1.0 into all maintained Fedora releases, it is the only version upstream takes bugs against and it is a substantial improvement on all levels.Then why isn't it in Fedora? The package in Fedora ATM is in violation of the Fedora Packaging Guidelines that are currently written. Not only that, it is in violation of a Guideline that bears on security. That binary package should not be in Fedora. If Banshee-1 fixes that problem and we are not competent enough to fix the issue through a backport or removing the specific feature that causes the issue at the downstream level then the package should start using a snapshot.
However, your explanation of the reason we use the prebuilt Boo.dll instead of system libraries points out that this is not the case. If nothing else, banshee could depend on the system library and not be available for ppc. This would be a case where security is more important than fixing the unable-to-build on a specific platform bug.
For upstream to stop this behavior we could focus inward as well, they do this because they can't count on libraries being available, the slowness (and rather frightening absolute lack of progress most of the time) of our review process certainly does nothing to help that. We need to do better at this step, then the prebuilt issue will go away without any work. It is my experience that once upstream can count on the libraries being available they will use them. It's not an upstream problem, we are helping to cause it.banshee, or indeed, mono, is not special in this regard. Many OSS and proprietary projects have to deal with this same issue. The proper thing for an upstream proprietary product to do is to create build scripts that detect whether the platform provides the needed libraries. If not, then the software uses an internal copy. For an OSS upstream, the software should compile the source of an internal copy. For Fedora as a downstream, we need to be adding each third party library to our repository and then using the upstream's build scripts to use the system libraries instead of what's internal. This will cause us to do more work at times and not be able to get things into our repositories as quickly as we'd like at others but it's what we do to meet our goals.
PS: Not that our goals can't change. Like I say, feel free to propose a draft for either of the two problems that apply to banshee:
http://fedoraproject.org/wiki/Packaging/Guidelines#SourceRequirementExceptions http://fedoraproject.org/wiki/Packaging/Guidelines#SystemLibraryDuplicationJust be sure to include persuasive rationale as this is something that I think contravenes the prevailing wisdom so it needs to have a lot of firm support.
-Toshio -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
