David Osguthorpe wrote:
On Thu, May 21, 2009 at 03:43:19AM -0600, Emmanuel Hainry wrote:
You should also drop bugfixing for anything not macosx (linux, bsd,
puredarwin). Jordan's plan would mean you can remove a lot of code
from
base: why are there different gcc default, different x11prefix? Why
should you care that some people use powerpc architectures, their
machines should already be dead (mine is) so only supporting the next
macosx release should be okay.
Only supporting Snow Leopard seems a bit narrow, in terms of
platforms...
I think it would make sense to keep the +puredarwin variant now that
puredarwin.org are using it to provide software for the Darwin 9 OS ?
Not supporting the previous releases (Darwin 7.0 and Darwin 8.0) seems
reasonable, even though MacPorts still did work OK on those as well.
Support for FreeBSD was revived in order to have a free OS platform to
test it on, and then GNU/Linux was added just to test the portability.
Neither of those are very serious, in terms of actual available ports,
even they do come in handy some times for mirroring and other purposes.
But neither (pure/bsd/gnu) is "supported" like Mac OS X is, of course.
I really get concerned when I see statements like this - so much
that I start
thinking maybe forking macports to eg. linuxports is needed - or
maybe back
to darwinports
...
One if the things that I like about Darwinports/Macports was the
encapsulation of the
building of open source projects - I do a lot of downloading
software and adding my own
personalizations and Ive found the Portfile approach relatively
easy to adapt for this
(yes Ive made my own SPEC files for rpms and Portfiles seemed much
simpler to the Fink
Makefiles which Ive looked at and what Ive seen of dpkgs so far for
Ubuntu doesnt seem easy)
so Im seriously thinking about using "LinuxPorts" on the Linux side
to control
software I might download and add changes to
...
By keeping to very basic generic Unix tools/options/commands you
can solve the above
problems and keep Darwinports/Macports working for as many systems
as possible
It should be _easier_ to run MacPorts on other platforms now that the
Foundation requirement (e.g. GNUstep) has been made optional instead ?
Ironically it was the Tcl requirement that was causing the problems on
newer Linux, since it doesn't always come with the threaded capability
that MacPorts requires (for instance Fedora's tcl package doesn't work),
even if for instance mtree and gnustep weren't normally available
either.
There are several things, like user creation or service starting/
stopping,
that needs porting to other operating systems if it should be usable
there.
And probably a large number of ports also would need some minor
patching or
adjustments before they would run on other platforms, due to
hardcoding Mac.
But it should still be "possible" to install MP 1.7 on Linux, even if
there
were no packages* made for it - due to the lack of cross-platform
interest...
--anders
* Like the ones for MP 1.6: http://trac.macports.org/browser/users/
afb/GA
Packages were available for FreeBSD (tbz), Fedora (rpm) and Ubuntu
(deb)
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
