Alexander Leidinger wrote at 19:35 +0200 on May 24, 2008:
> Removing unwanted stuff in post-extract is not uncommon. I don't think
> a patch for linux-rpm.mk with something like this would be a bad
> solution.
Removing things in post-extract _should_ be uncommon. If I want
to look at the extra
Doug Barton wrote at 13:45 -0800 on Jan 12, 2008:
> I have actually advocated in the past that ALL ports should have version
> numbers, and that we then create virtual ports (symlinks, whatever) that
> point to whatever is the "current" version of that software. Different
> developers dislik
Aryeh M. Friedman wrote at 23:53 -0400 on Oct 24, 2007:
> ===> Configuring for lsof-4.79C
> Unknown FreeBSD release: 8.0-CURRENT
> Assuming FreeBSD 2.x
> ./Configure: /usr/sbin/sysctl: not found
Until sysutils/lsof is updated for 8.x, try this when
running your portupgrade:
env LSOF_VSTR=7.0
Careful about using USE_LDCONFIG with linux ports.
With the current ports infrastructure you may wind up running ldconfig
on the native ldconfig database (i.e., without -r /compat/linux).
As an example, try replacing INSTALLS_SHLIB=yes with USE_LDCONFIG=yes
in x11/linux-xorg-libs/Makefile. Then
>Submitter-Id: current-users
>Originator: John E. Hein
>Organization:
>Confidential: no
>Synopsis: update to opentaxsolver 4.01 (for 2006)
>Severity: non-critical
>Priority: low
>Category: ports
>Class: maintainer-update
>Release:
Gábor Kövesdán wrote at 21:44 +0200 on Aug 23, 2006:
> Kris Kennaway wrote:
> > mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
> > mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
> > mount_devfs foo ${DESTDIR}/dev
> > chroot ${DESTDIR} cd ${.CURDIR} && make install
> >
> > A suitable version of t
Kris Kennaway wrote at 13:36 -0400 on Aug 16, 2006:
> mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
> mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
> mount_devfs foo ${DESTDIR}/dev
> chroot ${DESTDIR} cd ${.CURDIR} && make install
>
> A suitable version of the above should allow all ports to b
Gábor Kövesdán wrote at 11:32 +0200 on Aug 15, 2006:
> Dmitry Marakasov wrote:
> > Now, I think the way DESTDIR-related changes were done to bsd.port.mk is
> > absolutely wrong. For example, X11BASE, LOCALBASE, DATADIR now contain
> > DESTDIR. But, these variables are frequently used when chang
Brooks Davis wrote at 09:05 -0500 on Aug 10, 2006:
> My inclination would be something like:
>
> PKG_INSTALL_TEMP=`mktemp ${DESTDIR}/tmp/pkg_install` && \
> (${CAT} ${PKG_INSTALL} > ${PKG_INSTALL_TEMP}; \
> ${SH} ${PKG_INSTALL_TEMP}; \
> ${RM} ${PKG_INSTALL_
John E Hein wrote at 11:55 -0600 on Aug 10, 2006:
> Brooks Davis wrote at 09:05 -0500 on Aug 10, 2006:
> > I think we should ideally introduce a feature to allow ports to
> > automatically run pkg-install and stuff the code in bsd.port.mk so
> > ports don't hav
Gábor Kövesdán wrote at 01:47 +0200 on Aug 10, 2006:
> Ah, you mean defining CHROOTDESTDIR only when DESTDIR is set and leave
> it empty when not? It sounds reasonable then. I'll work this out after
> some hours of sleeping. :)
Yep... that's it.
__
John E Hein wrote at 17:43 -0600 on Aug 9, 2006:
> Well, the part that makes it annoying to duplicate in all ports is not
> the two separate words (CHROOT DESTDIR), but that you have to test
> defined(DESTDIR) && !empty(DESTDIR) before you can figure out whether
> to use
Gábor Kövesdán wrote at 01:29 +0200 on Aug 10, 2006:
> John E Hein wrote:
> > John E Hein wrote at 16:31 -0600 on Aug 9, 2006:
> > > Now that ports/Mk does the right thing for DESTDIR (thanks to Gábor),
> > > here's a patch that supports DESTDIR prope
Chuck Swiger wrote at 10:44 -0400 on Jul 20, 2006:
> > If the porter listed A as the dependency and libfoo is already
> > installed via B, what is the mechanism in the ports infrastructure by
> > which B gets registered as the dependency?
>
> The package database keeps track of all files inst
Chuck Swiger wrote at 09:39 -0400 on Jul 20, 2006:
> John E Hein wrote:
> > Let's say there are two ports A & B.
> > They both provide libfoo.so.1 (and so register CONFLICTS with each other).
> >
> > Now port C wants to use libfoo (and doesn
Let's say there are two ports A & B.
They both provide libfoo.so.1 (and so register CONFLICTS with each other).
Now port C wants to use libfoo (and doesn't care if it gets it
from A or B).
What does port C list in it's LIB_DEPENDS?
What if it lists A and someone installs B... does A get register
16 matches
Mail list logo