Re: What to do about dependencies...

On Jan 31, 2004, at 23:10, Benjamin Reed wrote:

> Jordan Hubbard wrote:
>
>> B) Make Toby finish his "groups" enhancement so we can make all of 
>> the existing X11 ports group themselves into the X11 group.  The 
>> group declaration code for X11 will then establish a *conditional* 
>> dependency on XFree86 if it can't find a full installation of it 
>> already on the system (checking for "markers" like xterm and 
>> libX11.a).  Then we only have a single location we need to change if 
>> we come up with better ways of dealing with this in the future and 
>> all those X11 ports don't need to duplicate the go-look-for-it code, 
>> they just swap their existing "depends_lib lib:libX11.6:XFree86" (or 
>> depends_run bin:xterm:..) lines for a "group x11" and they're done.
>> What to people think?
>
> If it helps any, this is kind of how it works in Fink.  In most cases, 
> we always depend on packages from Fink, but in cases where it is 
> possible to cleanly interact with existing system implementations of 
> things, fink makes "virtual" packages internally that meet the 
> dependencies, based on the existence of some files (essentially like 
> your current regex stuff, implemented in perl).
>
> We provide virtuals for X11, java, and a few other things that you 
> guys handle with variants and platform stuff (darwin version, macosx 
> version, available gcc version(s), etc.)
>

I think that the ultimate solution for this will be something like the 

distfiles.opendarwin.org addition

What's the procedure (if any yet) for adding a file to
distfiles.opendarwin.org?

Bryan

Re: What to do about dependencies...

On 1/2/04 1:35 am, Markus W. Weissmann <mww <at> opendarwin.org> wrote:

> 
> On Jan 31, 2004, at 23:10, Benjamin Reed wrote:
> 
>> Jordan Hubbard wrote:
>> 
>>> B) Make Toby finish his "groups" enhancement so we can make all of
>>> the existing X11 ports group themselves into the X11 group.  The
>>> group declaration code for X11 will then establish a *conditional*
>>> dependency on XFree86 if it can't find a full installation of it
>>> already on the system (checking for "markers" like xterm and
>>> libX11.a).  Then we only have a single location we need to change if
>>> we come up with better ways of dealing with this in the future and
>>> all those X11 ports don't need to duplicate the go-look-for-it code,
>>> they just swap their existing "depends_lib lib:libX11.6:XFree86" (or
>>> depends_run bin:xterm:..) lines for a "group x11" and they're done.
>>> What to people think?
>> 
>> If it helps any, this is kind of how it works in Fink.  In most cases,
>> we always depend on packages from Fink, but in cases where it is
>> possible to cleanly interact with existing system implementations of
>> things, fink makes "virtual" packages internally that meet the
>> dependencies, based on the existence of some files (essentially like
>> your current regex stuff, implemented in perl).
>> 
>> We provide virtuals for X11, java, and a few other things that you
>> guys handle with variants and platform stuff (darwin version, macosx
>> version, available gcc version(s), etc.)
>> 

Re: What to do about dependencies...

Chris Ridd said:
>>
>> On Jan 31, 2004, at 23:10, Benjamin Reed wrote:
>>
>>
>> I think that the ultimate solution for this will be something like the
>> virtual apt-packages from fink;
>> XFree86 and other components usable from the system will have a
>> 'virtual' variant that will do nothing (perhaps some symlinks?)
>> but satisfy the dependency from X11 apps. This way we'll avoid any
>> tricks with toby@'s group stuff and won't create stuff that
>> perhaps does not work as intended on other OS.
>> So on MacOS you do a 'port install XFree86 +virtual'; or perhaps we
>> should just make this the default case;
>
> It would be kind of nice if dp could sniff the system receipts and
> register
> them as virtual packages automatically, instead of doing things by hand.
>
> One problem I can see is that you could validly end up with two installed
> versions of something, like (random example!) libiconv - one in /usr/lib
> and
> one in /opt/local/lib. From my limited understanding of Will's registry
> overhaul, this isn't catered for.

I think that sniffing the system receipts is the cleanest approach,
however,  rather than register a virtual package, I'd recomend that DP
support the system's receipts 'natively', and the dependency
specifications be improved so that one could specify a dependency on
either the DarwinPorts XFree86, or the Mac OS X XFree86.

error: /opt/local/bin/kde-config

Hi,

I've just finished installing the kdebase3 successfully.  I then tried 
to install kdepim3 and got the following error while configuring:

--->  Configuring kdepim3
Error: Target com.apple.configure returned: configure failure: shell 
command "cd 
"/Users/yosuke/darwinports/dports/x11/kdepim3/work/kdepim-3.1.2" && 
CPPFLAGS='-I/usr/X11R6/include -I/opt/local/include 
-I/opt/local/include/qt3 -no-cpp-precomp -fno-common' 
LDFLAGS='-L/usr/X11R6/lib' LIBS='-L/opt/local/lib' 
DYLD_LIBRARY_PATH='/usr/X11R6/lib:/opt/local/lib' ./configure 
--prefix=/opt/local --prefix='/opt/local' 
--includedir='/opt/local/include' --libdir='/opt/local/lib' 
--with-extra-includes='/opt/local/include' 
--with-extra-libs='/opt/local/lib' --with-qt-dir='/opt/local' 
--with-qt-includes='/opt/local/include/qt3' --enable-rpath --with-pic 
--enable-shared=yes --enable-static=no --enable-mt 
--libexecdir='/opt/local/lib' --with-xinerama --with-pam --enable-final 
--disable-dependency-tracking" returned error 1
Command output: /usr/X11R6/lib/libGL.1.dylib undefined reference to 
_glVertex2fv expected to be defined in OpenGL
/usr/X11R6/lib/libGL.1.dylib undefined reference to _glVertex2i 
expected to be defined in OpenGL
/usr/X11R6/lib/libGL.1.dylib undefined reference to _glVertex2iv 
expected to be defined in OpenGL
. . .
/usr/X11R6/lib/libGL.1.dylib undefined reference to _glViewport 
expected to be defined in OpenGL

Re: cross category

On Sat, Jan 31, 2004 at 11:03:10PM +0100, Paul Guyot wrote:

> Has anyone an objection about creating a cross directory as on NetBSD 
> for cross-gcc compilers?
> I have a couple of ports ready for this category.

thumbs-up from me.

-fkr
--

-- 
gpg-fingerprint: 076E 1E87 3E05 1C7F B1A0  8A48 0D31 9BD3 D9AC 74D0 
Felix Kronlage  | FKR-RIPE        | http://www.hazardous.org/fkr/
fkr@{grummel.net|opendarwin.org}  | http://opendarwin.org/~fkr/ 

_______________________________________________
Darwinports mailing list
Darwinports <at> opendarwin.org
http://www.opendarwin.org/mailman/listinfo/darwinports

Re: What to do about dependencies...

> I think that sniffing the system receipts is the cleanest approach,
> however,  rather than register a virtual package, I'd recomend that DP
> support the system's receipts 'natively', and the dependency
> specifications be improved so that one could specify a dependency on
> either the DarwinPorts XFree86, or the Mac OS X XFree86.

So that would solve the OS X case, but then that means for this 
approach to be cross platform, you also need to support native RPM, 
*BSD pkg_*, solaris pkg*, etc.  Or am I misunderstanding and this is 
going to be an OS X only solution?
Jason

Re: What to do about dependencies...

Jason Corley wrote:

>> I think that sniffing the system receipts is the cleanest approach,
>>  however,  rather than register a virtual package, I'd recomend 
>> that DP support the system's receipts 'natively', and the 
>> dependency specifications be improved so that one could specify a 
>> dependency on either the DarwinPorts XFree86, or the Mac OS X 
>> XFree86.
> 
> 
> So that would solve the OS X case, but then that means for this 
> approach to be cross platform, you also need to support native RPM, 
> *BSD pkg_*, solaris pkg*, etc.  Or am I misunderstanding and this is
>  going to be an OS X only solution? Jason

yes, it would be a sad choice for portability.
i think the best solution would be to keep virtual package and maybe for
Xfree86 have an automatic virtual package create along DP install.
but in all case, virtual package need a good way to handle major/minor
release and eventually corresponding variants (detect or force a user 
choice).

for example a build of vnc on macosx 10.3+X11 doesn't need DP X11, but
it does on openbsd+X11 (event with removal of major number in depends_lib)

i think Xfree86 (by it's size), is main package, anyone will avoid to
compile, but we have to make the same with nearly anything (gcc, tcl, 
tk, ...)

Regards

Re: distfiles.opendarwin.org addition

I run a script nightly that does a checkout, attempts to reconcile
any duplicate distfiles/conflicting md5's with fink, and fetches
the distfile from the list of URL's the port returns.
Obviously, this means distfiles cannot be an authoritative place,
otherwise, it will never be able to get the file from its self.

Rob

On Sun, Feb 01, 2004 at 01:44:32AM -0700, Bryan Blackburn wrote:
> What's the procedure (if any yet) for adding a file to
> distfiles.opendarwin.org?
> 
> Bryan
> 
> _______________________________________________
> Darwinports mailing list
> Darwinports <at> opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/darwinports

Re: What to do about dependencies...

On Feb 1, 2004, at 11:07 AM, Jason Corley wrote:

>> I think that sniffing the system receipts is the cleanest approach,
>> however,  rather than register a virtual package, I'd recomend that DP
>> support the system's receipts 'natively', and the dependency
>> specifications be improved so that one could specify a dependency on
>> either the DarwinPorts XFree86, or the Mac OS X XFree86.
>
> So that would solve the OS X case, but then that means for this 
> approach to be cross platform, you also need to support native RPM, 
> *BSD pkg_*, solaris pkg*, etc.  Or am I misunderstanding and this is 
> going to be an OS X only solution?

I would be the first to chime in saying that I don't really think this 
is a good idea.  If we choose to support OS X packages natively, then I 
think we must also have a similar mechanism for the BSDs, Solaris... 
indeed every platform we intend to support.  That would cause us some 
problems with the BSDs, for example, because the base systems aren't 
package installed.  Anyway, in my view, an OS X-only solution is 
absolutely 100% unacceptable.

I've been thinking about this for a while now, and I also don't really 
like the Fink approach, though it is better in my mind than the 
proposal above.  Having virtual packages that sit in place of things 
already installed by the system.  To do so, we would need to detect 
what, out of these system packages, are already available (since we 
can't just assume that everything provided by OS X is available on 
FreeBSD, etc... unless we want to do OS-specific cases, which is just 
as bad as the above proposal).