On Tue, Aug 19, 2014 at 9:59 PM, Richard Shaw <[email protected]> wrote: > On Tue, Aug 19, 2014 at 2:05 PM, Ray Donnelly <[email protected]> > wrote: >> >> Which leads me naturally to ask: >> >> "Any chance of a mingw-w64-KiCad/PKGBUILD appearing?" ;-) > > > > That brings up something I was just thinking about. Is the mingw repository > really the correct place for end user programs? To me, the current division > between msys and mingw-w64 is: > > msys2: For helper programs needed to build mingw libraries and executables, > especially those that need bash or autotools to build > mingw-w64: Pre-built libraries so you don't have to bring up a whole > developer environment/dependency chain for every project you want to build. >
Wait a minute, I've got to find my bikeshed paint :-) msys2: PKGBUILDs and patches for programs that link to msys-2.0.dll and pretend to be a bit Unixy. These only exist to help make .. mingw-w64: The end goal, a set of PKGBUILDs and patches for building anything and everything Open Source on Windows using free tools. I don't mind that developers initially see mingw-w64 as a quick start way to get the libraries and compilers that they need installed so their own build scripts don't need to bother, but I hope they then realize that it is even better to get their Open Source programs included into mingw-w64 (or even set up their own private repository if they aren't working on OS stuff or just don't like to share). .. the boundary between tool and end user programs isn't well defined. Is Python a tool or an end user program? It depends on what you're doing with it. You'd soon get spaghetti dependencies going back and forth between the repos and spend time deciding and wondering if you added something to the right one. Arch Linux don't have this split (they have one main repository of packages and then one of community packages, and the AUR) and I generally fall back to "what does Arch do?" > Would it be cleaner to have a separate repository for "end user programs" > for which upstream doesn't already provide a native build/installer? I think there's an implication here that we don't (shouldn't?) package stuff that upstream already have installers for? I disagree with this, I don't see MSYS2 as a substitute for upstream binary packages, rather an alternative. I'd prefer that the upstream projects built their software in MSYS2 first (and maintained the PKGBUILD(s) for their software in our github repos) then made an installer based on built binary packages, like nacho did for a gedit release recently: http://blogs.gnome.org/nacho/ .. ultimately, I hope to get away from using installers altogether since "pacman -Syu" is much easier than looking at the homepages of all your installed apps to see if there's a new version out yet, then fetching and installing it manually. In summary, we're more like a Linux distribution and less like some developer toolkit. > > Thanks, > Richard > > ------------------------------------------------------------------------------ > > _______________________________________________ > Msys2-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/msys2-users > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
