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

Re: Proposed removal of packages with long-standing FTBFS failures


Hmmm, HTML posting... Not nice... Shame on you all!

>         I haven't touched the F-9 branch; as I'm not running F-9
>         anymore, and
>         with the changes in the Mono stack, I didn't want to risk any
>         breakage. Paul likely knows more about the difference between
>         F-9's
>         mono and Rawhide's -- Paul, you could perhaps backport the
>         Rawhide
>         monodevelop to F-9? Some of the BRs might need to be changed.
> I believe the new monodevelop requires gtk-sharp-2.12 which in return
> will require us to push everything that depends on gtk-sharp2 (with
> patches or updated versions from rawhide). 

It requires gnome-sharp-desktop as well, so there would be a large
number of packages required for the new MD to be brought into F9.

> I would be in favor of this as it would make our Mono stack a bit more
> consistent across the supported platforms and it would allow us to
> have the same supported versions of many programs on every platform.
> Something like gnome-do e.g. is generally only supported in the latest
> release by upstream and we cannot put that in F9 because our stack
> cannot support it currently.

Correct. This is one of the biggest reasons why my support for F9 is
much slower, the changes in rawhide are massive and to backport many of
them would break more than they would fix.

> Maybe once Mono 2.0 Final hits we can decide if a coordinated push to
> F9 (and F8 if it is still supported at such a time) is desirable, that
> would give us time to clean everything up and maybe the friendly ppc
> arch team can help us fix nant as well so ppc users can get a complete
> mono stack.

Mono 2.0 is due for release in the next week or so, so it should be
there fully in F10 (though it will be a race!). I'd be much happier with
F9 to have the 1.9.1 release (or even a full blown 2.0 release). This
would make things a damned sight simpler to keep up to date.

It would though need all the mono contributors to co-ordinate a single
push. First mono/libgdiplus/mono-basic then gtk stack then
MD/nant/mono-tools/monodoc/mono-addins then whatever else is there.

Anyone interested in a mono-SIG? It could be useful!



Sie können mich aufreizen und wirklich heiß machen!

Attachment: signature.asc
Description: This is a digitally signed message part

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