Re: Mono Package audit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





2008/4/10, Toshio Kuratomi <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.

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.

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.

- David
-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux