Re: Alternatives to rsync
If you want block efficient, then zfs is your friend 1) make the 'dir' be a distinct zfs filestore in the zpool 2) run zfssnap on some duty cycle 3) profit seriously: as long as the copy can be maintained readonly, in sync with the source, the block level copy of zfs snapshots under some serial/time cycle, does the job. I ran this over mbuffer to get around ssh insane packet behaviour, I only stopped when the client wanted to prune the copy and it ceased to be a zfs snapshot copy. Its much faster than rsync. Its at the filesystem block level. On Thu, Oct 13, 2016 at 3:59 PM, Franco Fichtner wrote: > >> On 13 Oct 2016, at 6:39 AM, reko.turja--- via freebsd-ports >> wrote: >> >> The software should be relatively lightweight - no fullblown >> mirroring/backup is needed. Also hints how to achieve similar ends using >> maybe tar/ssh might do. > > Try cpdup(1). > > > Cheers, > Franco > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Alternatives to rsync
> On 13 Oct 2016, at 6:39 AM, reko.turja--- via freebsd-ports > wrote: > > The software should be relatively lightweight - no fullblown mirroring/backup > is needed. Also hints how to achieve similar ends using maybe tar/ssh might > do. Try cpdup(1). Cheers, Franco ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Alternatives to rsync
1. rsync IS open source: https://rsync.samba.org/ "rsync is an open source utility" 2. Why is GPL3 out of the question? Is the user going to resell the device as a service? If the user is simply "using" the software, no disclosure of other software is necessary. Only if your user is attempting to "make money" from the sale of the software or service powered by rsync does the source need to be disclosed. If the user simply wants to use rsync for their own purposes, GPL3 does not prevent them from doing so nor does it require that the user disclose all code written. If the user IS going to make money off of using rsync, you are correct. Beckman On Thu, 13 Oct 2016, reko.turja--- via freebsd-ports wrote: One of my users is needing rsync like functionality to transfer changed contents of some directories between couple of machines. As rsync 3 isn't open source, but GPL3 it's out of question in order to keep the system untainted. The software should be relatively lightweight - no fullblown mirroring/backup is needed. Also hints how to achieve similar ends using maybe tar/ssh might do. -Reko ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ --- ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Alternatives to rsync
One of my users is needing rsync like functionality to transfer changed contents of some directories between couple of machines. As rsync 3 isn't open source, but GPL3 it's out of question in order to keep the system untainted. The software should be relatively lightweight - no fullblown mirroring/backup is needed. Also hints how to achieve similar ends using maybe tar/ssh might do. -Reko ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qa.sh stripped warning
Hi, On Wed, Oct 12, 2016 at 10:35 AM, Mathieu Arnold wrote: > The warning will never be turned into errors. Maybe add a comment to the > makefile saying that files must not be stripped. Maybe a bit like go > ports do it, something like: > > STRIP= # Elf firmwares, do not strip Thanks for the suggestion! I've implemented this. Given the strong wording you've used here (will never be turned into errors), would you consider revising the comment @ https://svnweb.freebsd.org/ports/head/Mk/Scripts/qa.sh?view=markup#l191 ? It's easy to derive uncertainty from the wording used in the comment. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: protobuf 3.1.0
Hi! > When I went to do a pull request they said the issue does not exist with > protobuf 3.1.0 > https://github.com/pstavirs/ostinato/issues/199 > > My poudriere server succfuly built net/ostinato > http://45.62.227.38/build.html?mastername=amd64-testing&build=2016-10-12_17h10m03s > and I have not applyed that patch Ah, ok. I'll test without any patch, then. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: protobuf 3.1.0
When I went to do a pull request they said the issue does not exist with protobuf 3.1.0 https://github.com/pstavirs/ostinato/issues/199 My poudriere server succfuly built net/ostinato http://45.62.227.38/build.html?mastername=amd64-testing&build=2016-10-12_17h10m03s and I have not applyed that patch From: Kurt Jaeger Sent: Wednesday, October 12, 2016 4:06:10 PM To: E.J. Bevenour Cc: freebsd-ports@freebsd.org Subject: Re: protobuf 3.1.0 Hi! > Hi, I have submitted two patches to fix zbackup for protobuf 3.1.0 at > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212973 > > I am wondering if this can be resolved as soon as possible. I'm testbuilding net/ostinato with protobuf 3.1.0 and it fails to build. Your patch to net/ostinato in PR#212973 is marked obsolete, can you explain, why ? -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: protobuf 3.1.0
Hi! > Hi, I have submitted two patches to fix zbackup for protobuf 3.1.0 at > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212973 > > I am wondering if this can be resolved as soon as possible. I'm testbuilding net/ostinato with protobuf 3.1.0 and it fails to build. Your patch to net/ostinato in PR#212973 is marked obsolete, can you explain, why ? -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: protobuf 3.1.0
Hi! > Hi, I have submitted two patches to fix zbackup for protobuf 3.1.0 at > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212973 > > I am wondering if this can be resolved as soon as possible. I'll have a look, with 3.1.0, and I'll testbuild... It'll take a while. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
protobuf 3.1.0
Hi, I have submitted two patches to fix zbackup for protobuf 3.1.0 at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212973 I am wondering if this can be resolved as soon as possible. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: qa.sh stripped warning
Le 12/10/2016 à 16:29, Kyle Evans a écrit : > Hello! > > I've got a port with a dozen+ ELF binaries for microcontroller > firmware that I don't think I should be stripping, but qa.sh does not > like this. They're *.elf and *.lib files, so I don't know that adding > these to the general exception of `find` in stripped() is necessarily > a good idea, but it seems like a way to add exceptions for this would > it be a good idea, whether it be through some setting in the port or > on a case-by-case basis in the pkg-plist.. thoughts? > > My main concern here is that I don't intend to strip these, but the > comment for stripped() would leave me to believe that there's a chance > these warnings could eventually turn into errors, and I don't want > this to be the case if it's not something that should be stripped. The warning will never be turned into errors. Maybe add a comment to the makefile saying that files must not be stripped. Maybe a bit like go ports do it, something like: STRIP= # Elf firmwares, do not strip Which also disables the qa warnings. -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
qa.sh stripped warning
Hello! I've got a port with a dozen+ ELF binaries for microcontroller firmware that I don't think I should be stripping, but qa.sh does not like this. They're *.elf and *.lib files, so I don't know that adding these to the general exception of `find` in stripped() is necessarily a good idea, but it seems like a way to add exceptions for this would it be a good idea, whether it be through some setting in the port or on a case-by-case basis in the pkg-plist.. thoughts? My main concern here is that I don't intend to strip these, but the comment for stripped() would leave me to believe that there's a chance these warnings could eventually turn into errors, and I don't want this to be the case if it's not something that should be stripped. Thanks, Kyle Evans ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
install header files required for development with libzfs_core
JFYI. I bumped __FreeBSD_version to 1200013 to mark this change.
Forwarded Message
Subject: svn commit: r307131 - head/include
Date: Wed, 12 Oct 2016 07:08:32 + (UTC)
From: Andriy Gapon
To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
svn-src-h...@freebsd.org
Author: avg
Date: Wed Oct 12 07:08:32 2016
New Revision: 307131
URL: https://svnweb.freebsd.org/changeset/base/307131
Log:
install header files required development with libzfs_core
libzfs_core provides a rather limited but committed (stable) interface
for working with ZFS. We install libzfs_core shared library but we do
not install header files required for developing programs that use
the library. This change is to install the required header files
libzfs_core.h, libnvpair.h and sys/nvpair.h.
The headers are installed into the same locations as on illumos.
Reviewed by:mav, markj
Differential Revision: https://reviews.freebsd.org/D8005
Modified:
head/include/Makefile
Modified: head/include/Makefile
==
--- head/include/Makefile Wed Oct 12 06:58:01 2016(r307130)
+++ head/include/Makefile Wed Oct 12 07:08:32 2016(r307131)
@@ -237,6 +237,17 @@ copies: .PHONY .META
cd ${.CURDIR}/../sys/teken; \
${INSTALL} -C ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m 444 teken.h \
${DESTDIR}${INCLUDEDIR}/teken
+.if ${MK_CDDL} != "no"
+ cd ${.CURDIR}/../cddl/contrib/opensolaris/lib/libzfs_core/common; \
+ ${INSTALL} -C ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m 444
libzfs_core.h \
+ ${DESTDIR}${INCLUDEDIR}
+ cd ${.CURDIR}/../cddl/contrib/opensolaris/lib/libnvpair; \
+ ${INSTALL} -C ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m 444 libnvpair.h \
+ ${DESTDIR}${INCLUDEDIR}
+ cd ${.CURDIR}/../sys/cddl/contrib/opensolaris/uts/common/sys; \
+ ${INSTALL} -C ${TAG_ARGS} -o ${BINOWN} -g ${BINGRP} -m 444 nvpair.h \
+ ${DESTDIR}${INCLUDEDIR}/sys
+.endif
symlinks: .PHONY .META
@${ECHO} "Setting up symlinks to kernel source tree..."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 12/10/2016 8:12 PM, Matthew Seaman wrote: > On 2016/10/12 09:43, Kubilay Kocak wrote: >>> You are describing the 'sub-packages' concept that has been >>> knocking around for some time. With sub-packages you'ld divide up the result of staging each port into various chunks: >> Yep, like this: >> >> Mar 6 2016 - https://reviews.freebsd.org/D5563 Ports framework >> "variants" proof-of-concept (with poudriere support) >> >> Status Report Dec 2015 - Supporting Variants in the Ports >> Framework >> >> https://www.freebsd.org/news/status/report-2015-10-2015-12.html#Supporting-Variants-in-the-Ports-Framework > >> > Variants is a related but different concept -- known as 'flavours' > (or 'flavors') in some parts. The difference is that 'sub packages' > divide up the output from one compilation of the sources, whereas > 'variants' or 'flavours' require the same source code to be > recompiled with different options. (As you'ld need to do to create > eg. py27- and py34- versions of python modules.) Both are things we'd > like to have in ports, but they can be implemented pretty much > separately. They could be, but they don't need to be. From one perspective, division of a port (or package) is exactly a 'variant'. Yes a 'part' (-debug package) of a whole (-full package) is a "sub package", but the 'debug' variant of the foo port only includes debug files, and has a -debug suffix. Variants (in its current PoC form) is just a generic implementation for enabling one-to-many-packages, and is not prescriptive. The 'what to Vary: on' (like the HTTP headers), including perhaps what to include or exclude from the package, is left as a exercise for the configuration, or portmgr or a later stage discussion. There is nothing explicitly prescribing that specified 'variants' must compile source each time (or do anything else specific for that matter), or that said variants cannot merely execute the "dividing up" (on some basis) logic on the resulting artifacts that were created in the common/base 'variant'. > Cheers, > > Matthew ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 2016-10-12 10:27, Julian Elischer wrote:
what I really need is a RUNTIME option that produces a package with
only those files needed to satisfy external run-time depdencies, or
the actual demands of the user itself. However since those files are
Right. But then the question is how do you define what is minimum
required code to satisfy external run time deps? Can the framework
assume it by path, or should the maintainers define it through options?
IMHO if the latter, then my suggestion is not to define any roles
("runtime") but define groups of files that can then be included in
whatever role. Eg, all include/... files be switched with HEADERS
option. Many ports already do DOCS, MANPAGES, EXAMPLES. So that's a set
criteria one can base -runtime variant upon:
OPTIONS_UNSET= HEADERS DOCS MANPAGES EXAMPLES
--
Vlad K.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 2016/10/12 09:43, Kubilay Kocak wrote: >> You are describing the 'sub-packages' concept that has been knocking >> > around for some time. With sub-packages you'ld divide up the result >> > of staging each port into various chunks: > Yep, like this: > > Mar 6 2016 - https://reviews.freebsd.org/D5563 > Ports framework "variants" proof-of-concept (with poudriere support) > > Status Report Dec 2015 - Supporting Variants in the Ports Framework > > https://www.freebsd.org/news/status/report-2015-10-2015-12.html#Supporting-Variants-in-the-Ports-Framework Variants is a related but different concept -- known as 'flavours' (or 'flavors') in some parts. The difference is that 'sub packages' divide up the output from one compilation of the sources, whereas 'variants' or 'flavours' require the same source code to be recompiled with different options. (As you'ld need to do to create eg. py27- and py34- versions of python modules.) Both are things we'd like to have in ports, but they can be implemented pretty much separately. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: harder and harder to avoid pkg
On 12/10/2016 5:55 PM, Matthew Seaman wrote: > On 11/10/2016 19:59, Julian Elischer wrote: >> As the number of dependencies between packages get ever higher, it >> becomes more and more difficult to compile packages and the >> dependence on binary precompiled packages is increased. However >> binary packages are unsuitable for some situations. We really need >> to follow the lead of some of the Linux groups and have -runtime >> and -devel versions of packages, OR we what woudlbe smarter, >> woudl be to have several "sub manifests" to allow unpacking in >> different environments. >> >> >> A simple example: libxml2 >> >> This package installs include files and libraries and dicumentation >> etc. >> >> yet if I build an appliance , I want it to only install a singe >> file. >> >> /usr/local/lib/libxml2.so.2 >> >> >> The presence of this file will satisfy any runtime dependencies of >> packages that require it. >> >> Unfortunately there is no way to install just this file, and still >> report that we have the package loaded, so >> >> pkg will always try to reinstall it leading to a huge mess. >> >> My current scheme is to unpack all packages into a larger staging >> area, and *manually* (scripted) copy out only the files I need, and >> then copy the pkg database, so that when run on the running >> appliance, pkg THINKS all the packages are loaded on the appliance, >> even though only the runtime files are installed. This is what we >> in the industry call "a hack" :-) It is also not robust in the >> face of changing pkg versions. >> >> It would be a lot better it pkg knew it was being asked to install >> only the runtime set, and coudl accurately store this information >> in its database, allowing it to satisfy the needs of other packages >> that need that dependnency only in a runtime manner. >> >> Is any of this possible at the moment? >> >> suggestions from the ports/pkg community are appreciated.. >> >> Julian > > You are describing the 'sub-packages' concept that has been knocking > around for some time. With sub-packages you'ld divide up the result > of staging each port into various chunks: Yep, like this: Mar 6 2016 - https://reviews.freebsd.org/D5563 Ports framework "variants" proof-of-concept (with poudriere support) Status Report Dec 2015 - Supporting Variants in the Ports Framework https://www.freebsd.org/news/status/report-2015-10-2015-12.html#Supporting-Variants-in-the-Ports-Framework > - binaries + config file samples + required data files (the core pkg > content) - shlibs - debug symbols - docs - examples - c/c++ headers > and static or profiling libs (ie. only required for compilation) - > various additional plugins etc. currently controlled by port options > > Each of these would be packaged separately and can be used > independently for resolving dependencies. Building each port would > result in as many of these sub packages as are applicable. > > Turning OPTIONS into sub-packages will also significantly reduce the > number of OPTIONS settings needed in the ports tree (I think bapt had > an estimate of about a 70% reduction but ICBW) and make the pkg > system significantly better able to handle more varied user > requirements without users having to compile their own packages. > > Unfortunately attention has been diverted while there's a lot of > work going on towards packaging base. The problem as far as ports > are concerned is producing several packages out of one port -- it's > not rocket science level of difficulty to make that change, but the > assumption of a one-to-one correspondence between ports and packages > is deeply rooted, and it's going to take a lot of work to unpick. Mar 6 2016 - https://reviews.freebsd.org/D5563 Ports framework "variants" proof-of-concept (with poudriere support) > Happily, the package sets produced for the base system are already > divided along these lines, so with a packaged base it is really very > easy to produce a stripped down and streamlined base system. > > Cheers, > > Matthew ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 12/10/2016 5:55 PM, Matthew Seaman wrote: > On 11/10/2016 19:59, Julian Elischer wrote: >> As the number of dependencies between packages get ever higher, it >> becomes more and more difficult to compile packages and the >> dependence on binary precompiled packages is increased. However >> binary packages are unsuitable for some situations. We really need >> to follow the lead of some of the Linux groups and have -runtime >> and -devel versions of packages, OR we what woudlbe smarter, >> woudl be to have several "sub manifests" to allow unpacking in >> different environments. >> >> >> A simple example: libxml2 >> >> This package installs include files and libraries and dicumentation >> etc. >> >> yet if I build an appliance , I want it to only install a singe >> file. >> >> /usr/local/lib/libxml2.so.2 >> >> >> The presence of this file will satisfy any runtime dependencies of >> packages that require it. >> >> Unfortunately there is no way to install just this file, and still >> report that we have the package loaded, so >> >> pkg will always try to reinstall it leading to a huge mess. >> >> My current scheme is to unpack all packages into a larger staging >> area, and *manually* (scripted) copy out only the files I need, and >> then copy the pkg database, so that when run on the running >> appliance, pkg THINKS all the packages are loaded on the appliance, >> even though only the runtime files are installed. This is what we >> in the industry call "a hack" :-) It is also not robust in the >> face of changing pkg versions. >> >> It would be a lot better it pkg knew it was being asked to install >> only the runtime set, and coudl accurately store this information >> in its database, allowing it to satisfy the needs of other packages >> that need that dependnency only in a runtime manner. >> >> Is any of this possible at the moment? >> >> suggestions from the ports/pkg community are appreciated.. >> >> Julian > > You are describing the 'sub-packages' concept that has been knocking > around for some time. With sub-packages you'ld divide up the result > of staging each port into various chunks: Yep, like this: Ports framework "variants" proof-of-concept (with poudriere support) Mar 6 2016 - https://reviews.freebsd.org/D5563 > - binaries + config file samples + required data files (the core pkg > content) - shlibs - debug symbols - docs - examples - c/c++ headers > and static or profiling libs (ie. only required for compilation) - > various additional plugins etc. currently controlled by port options > > Each of these would be packaged separately and can be used > independently for resolving dependencies. Building each port would > result in as many of these sub packages as are applicable. > > Turning OPTIONS into sub-packages will also significantly reduce the > number of OPTIONS settings needed in the ports tree (I think bapt had > an estimate of about a 70% reduction but ICBW) and make the pkg > system significantly better able to handle more varied user > requirements without users having to compile their own packages. > > Unfortunately attention has been diverted while there's a lot of > work going on towards packaging base. The problem as far as ports > are concerned is producing several packages out of one port -- it's > not rocket science level of difficulty to make that change, but the > assumption of a one-to-one correspondence between ports and packages > is deeply rooted, and it's going to take a lot of work to unpick. Ports framework "variants" proof-of-concept (with poudriere support) Mar 6 2016 - https://reviews.freebsd.org/D5563 > Happily, the package sets produced for the base system are already > divided along these lines, so with a packaged base it is really very > easy to produce a stripped down and streamlined base system. > > Cheers, > > Matthew ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/py-jep| 3.5.3 | 3.6.1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 12/10/2016 1:13 AM, Vlad K. wrote: On 2016-10-11 20:59, Julian Elischer wrote: are unsuitable for some situations. We really need to follow the lead of some of the Linux groups and have -runtime and -devel versions of packages, OR we what woudlbe smarter, woudl be to have several "sub manifests" to allow unpacking in different environments. Is as adding a "HEADERS" or whatever you want to call the option to ports, a solution? Like we have DOC for documentation, an option that could be PLIST sub'd and switch installation of include/whatever.h and friends? what I really need is a RUNTIME option that produces a package with only those files needed to satisfy external run-time depdencies, or the actual demands of the user itself. However since those files are all in the regular package, It'd make sense to just apply the regular package to some filter that only allowed those files to be extracted. For many packages the whole output would be a single file. (This would be true for any package that produces a single .so such as libjpeg or libtiff etc. ). The pkg database would however report the package being installed, thus satisfying other packages that look in the database for dependencies. Giving it another name (e.g. foo-runtime-3.2 ) would make the dependencies not match it. Yes it's a ton of work requiring to go through many ports, but looking at a random sample, it could be scripted and manual labor reduced. To me something like this sounds very much consistent what other options, like DOC and MANPAGES, already do. And with individual options you don't presume package roles like -dev or -runtime or -whatever and you can combine as you want them. And eventually if, hopefully when, package variants are implemented, maybe the official pkg repo can include all the variants, but then, I think, that's only a matter of logistics and resource available to build all those combinations and store them. But the basic mechanism for it should be a port option, imho. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 2016-10-11 20:59, Julian Elischer wrote: are unsuitable for some situations. We really need to follow the lead of some of the Linux groups and have -runtime and -devel versions of packages, OR we what woudlbe smarter, woudl be to have several "sub manifests" to allow unpacking in different environments. Is as adding a "HEADERS" or whatever you want to call the option to ports, a solution? Like we have DOC for documentation, an option that could be PLIST sub'd and switch installation of include/whatever.h and friends? Yes it's a ton of work requiring to go through many ports, but looking at a random sample, it could be scripted and manual labor reduced. To me something like this sounds very much consistent what other options, like DOC and MANPAGES, already do. And with individual options you don't presume package roles like -dev or -runtime or -whatever and you can combine as you want them. And eventually if, hopefully when, package variants are implemented, maybe the official pkg repo can include all the variants, but then, I think, that's only a matter of logistics and resource available to build all those combinations and store them. But the basic mechanism for it should be a port option, imho. -- Vlad K. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On 10/12/16 09:24, Matthieu Volat wrote: And GNU/Linuxes can be a PITA when you have to track -dev(el) packages (which sometimes really requires -bin, -app or whatever), or worst, describe to people how they are supposed to build your software with weird subpackage names. I really like that ports provides the software project as intended by upstream (modulo options). Just a "me too" here! bye av. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: harder and harder to avoid pkg
On Tue, 11 Oct 2016 11:59:47 -0700 Julian Elischer wrote: > As the number of dependencies between packages get ever higher, it > becomes more and more difficult to compile packages and the dependence > on binary precompiled packages is increased. However binary packages > are unsuitable for some situations. We really need to follow the lead > of some of the Linux groups and have -runtime and -devel versions of > packages, OR we what woudlbe smarter, woudl be to have several "sub > manifests" to allow unpacking in different environments. > [...] > And GNU/Linuxes can be a PITA when you have to track -dev(el) packages (which sometimes really requires -bin, -app or whatever), or worst, describe to people how they are supposed to build your software with weird subpackage names. I really like that ports provides the software project as intended by upstream (modulo options). -- Matthieu Volat pgpL0u4FDI6tS.pgp Description: OpenPGP digital signature
