search

gentoo / dotnet

[MIRROR] Newer mono, .NET languages, and libraries
https://gitweb.gentoo.org/repo/proj/dotnet.git
78 stars 56 forks source link

Gtk+ ebuilds and their packaging #131

Open ArsenShnurkov opened 9 years ago

ArsenShnurkov commented 9 years ago

Why it is documented so poorly, that no one can continue this work?

@gmt in IRC asks: "is the writing on the wall for modular gtk-sharp in gentoo? Or is dev-dotnet/gtk-sharp-2.12.21 some kind of stopgap measure? It was checked in to git without much of a changelog / commit-msg by Heather Cynede (@Heather). Is there some place I should be reading up if I want to understand the game-plan? Personally I just want cairo-dock-plugins to work :)"

Which documentation do we have? http://www.mono-project.com/docs/gui/gtksharp/ http://www.mono-project.com/docs/gui/gtksharp/tutorials/

"Gtk# 3.0 will be built against the .net 2.0 profile, but it will be possible to install 2.12 and 3.0 in parallel for compatibility." (q) http://www.mono-project.com/docs/gui/gtksharp/plan/ there is no more 2.0 profile (because MS opensourced 4.0, 4.5, 4.6), so we need a more modern plan

gmt commented 9 years ago

ArsenShnurkov wrote:

Why it is documented so poorly, that no one can continue this work?

Perhaps this question is unanswerable. Indeed the same could be asked of lots of vital gentoo components, like the toolchain and eutils eclasses, or glibc's "eblits" abomination.

The current state of affairs is that the stable branch and the testing branch of gx86 take different approaches:

As currently implemented, these approaches are difficult to support simultaneously in ebuilds that DEPEND on them. To preserve the two-prong status quo sustainably, the dotnet team would probably need to create virtuals (or a functional equivalent, i.e., a "dev-dotnet/gtk-sharp-meta") to prevent a profusion of DEPENDenceies like:

( || ( <=dev-dotnet/gtk-sharp-2.12.13[foolib] dev-dotnet/foo-sharp))

from appearing all over the place, which, although probably legal in EAPI5+, will bring portage's dep-solver to it's knees, in practice, causing all kinds of spooky disasters whenever any structural change occurs (and general slowness).

I think the questions that need answering are:

My $0.02: the fact that, i.e., bug 509398 has lingered for a year-and-a-half without someone simply merging Constantine's work or at least providing him with guidelines for how to make it acceptable suggests there is not a ton of demand out there. If that's so, then perhaps the modular ebuilds are simply overkill?

cnd commented 9 years ago

@gmt we should drop / deprecate old non-monolitic gtk-sharp ebuilds since nobody wants to maintain them and mark monolitic ones as stable. there are few errors currently and many stuff here needs some rework, alike moving monodevelop back from git sources into tarballs, resolving issues on bgo, etc...

gmt commented 9 years ago

Heather wrote:

@gmt we should drop / deprecate old non-monolitic gtk-sharp ebuilds since nobody wants to maintain them and mark monolitic ones as stable. there are few errors currently and many stuff here needs some rework, alike moving monodevelop back from git sources into tarballs, resolving issues on bgo, etc...

Right on, I'm inclined to agree with all of the above ... but only just looking into it. I didn't realize until just now that monolithic gtk-sharp:3 was already in the overlay.

What are your thoughts about migrating dependencies on the modular packages? Let individual packages sort it out? Or try to automagicate it with self-modifying dummy blocker ebuilds or something like that?

:kissing_smiling_eyes: ...

Just kidding about the self-modifying part. The rest was serious though :yum:

cnd commented 9 years ago

@gmt depending packages should use newer (monolithic) gtk-sharp ebuilds, I doubt there could be sane way of doing it without updating all depending packages.

gtk-sharp:3 not just in overlay, they should be in tree either

Hecatron commented 8 years ago

For info Gtk# 3.0 is now downloadble via Nuget, I've managed to run gtk# 3.0 apps on both windows and a rpi2 gentoo install With windows you use the GTK# and GTK#.Win32 packages for Linux you just need the GTK# package since it seems to pick up on gtk3 that's been installed on the system locally automatically

The installer on GTK#'s website appears to be for GTK2, but the NuGet packages are for GTK3 It's possible to also use the latest glade under windows or linux with the GTK3 version although instead of glade-sharp (with the GTK2 version) you need to use GTK.builder (GTK#3 equivilent) to load in the glade file