Installing a different PORTVERSION based on OSVERSION?
in [Ports]
|
From: Darren Pilgrim on 13 Feb 2010 22:26 I'm working on a revision to a port where the current version doesn't work on 8.0-R; however, an older version does. Rather than roll the entire port back to an older version, I'd like to have the newer version available to 7.x and older and the older version available to 8.x and newer. Is it appropriate to install different versions of a port based on ${OSVERSION}? If so, do I just set the necessary variables after including bsd.port.pre.mk? _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Wesley Shields on 14 Feb 2010 13:02 On Sat, Feb 13, 2010 at 07:26:39PM -0800, Darren Pilgrim wrote: > I'm working on a revision to a port where the current version doesn't > work on 8.0-R; however, an older version does. Rather than roll the > entire port back to an older version, I'd like to have the newer version > available to 7.x and older and the older version available to 8.x and > newer. Is it appropriate to install different versions of a port based > on ${OSVERSION}? If so, do I just set the necessary variables after > including bsd.port.pre.mk? This seems like a bad idea to me. How much effort would it take to fix the port on 8.x and newer? The other option is to mark it broken on 8.x and newer. -- WXS _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Darren Pilgrim on 14 Feb 2010 15:58 Wesley Shields wrote: > On Sat, Feb 13, 2010 at 07:26:39PM -0800, Darren Pilgrim wrote: >> I'm working on a revision to a port where the current version doesn't >> work on 8.0-R; however, an older version does. Rather than roll the >> entire port back to an older version, I'd like to have the newer version >> available to 7.x and older and the older version available to 8.x and >> newer. Is it appropriate to install different versions of a port based >> on ${OSVERSION}? If so, do I just set the necessary variables after >> including bsd.port.pre.mk? > > This seems like a bad idea to me. How much effort would it take to fix > the port on 8.x and newer? The port contains a static-linked binary from the vendor--not something I can patch. > The other option is to mark it broken on 8.x and newer. The port currently sets BROKEN if OSVERSION >= 800000. _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Garrett Cooper on 14 Feb 2010 16:48 On Sun, Feb 14, 2010 at 12:58 PM, Darren Pilgrim <freebsd(a)bitfreak.org> wrote: > Wesley Shields wrote: >> >> On Sat, Feb 13, 2010 at 07:26:39PM -0800, Darren Pilgrim wrote: >>> >>> I'm working on a revision to a port where the current version doesn't >>> work on 8.0-R; however, an older version does. Rather than roll the entire >>> port back to an older version, I'd like to have the newer version available >>> to 7.x and older and the older version available to 8.x and newer. Is it >>> appropriate to install different versions of a port based on ${OSVERSION}? >>> If so, do I just set the necessary variables after including >>> bsd.port.pre.mk? >> >> This seems like a bad idea to me. How much effort would it take to fix >> the port on 8.x and newer? > > The port contains a static-linked binary from the vendor--not something I > can patch. > >> The other option is to mark it broken on 8.x and newer. > > The port currently sets BROKEN if OSVERSION >= 800000. Vendor provided binaries are a fun ball of wax to deal with because you need to have all dependencies come from the same generic pool as the package [/ port] itself, as any This sounds trivial, but it requires changes to pkg_add (for fetching / installing a particular revision of the code, as well as `slotting' the packages themselves), determining elf-version, ld modifications, as well as a few other things. It's been implemented at my work [Ironport] from what I've been told, but 1) I'm not sure how complete it is, 2) I'm not sure how tested it is, and 3) it hasn't been reviewed yet and I'm not sure how much would be put back in the community at large to be honest... HTH, -Garrett _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Darren Pilgrim on 14 Feb 2010 17:20
Garrett Cooper wrote: > Vendor provided binaries are a fun ball of wax to deal with > because you need to have all dependencies come from the same generic > pool as the package [/ port] itself, as any > This sounds trivial, but it requires changes to pkg_add (for > fetching / installing a particular revision of the code, as well as > `slotting' the packages themselves), determining elf-version, ld > modifications, as well as a few other things. It's been implemented at > my work [Ironport] from what I've been told, but 1) I'm not sure how > complete it is, 2) I'm not sure how tested it is, and 3) it hasn't > been reviewed yet and I'm not sure how much would be put back in the > community at large to be honest... Or you can take the vendor's approach and make a static binary with all the dependencies (i.e., libraries) compiled in. _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org" |