Re: Alternatives to rsync

2016-10-12 Thread George Michaelson
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

2016-10-12 Thread Franco Fichtner

> 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

2016-10-12 Thread Peter Beckman

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

2016-10-12 Thread reko.turja--- via freebsd-ports
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

2016-10-12 Thread Kyle Evans
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

2016-10-12 Thread Kurt Jaeger
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

2016-10-12 Thread E.J. Bevenour

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

2016-10-12 Thread Kurt Jaeger
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

2016-10-12 Thread Kurt Jaeger
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

2016-10-12 Thread E.J. Bevenour
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

2016-10-12 Thread Mathieu Arnold
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

2016-10-12 Thread Kyle Evans
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

2016-10-12 Thread Andriy Gapon

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

2016-10-12 Thread Kubilay Kocak
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

2016-10-12 Thread Vlad K.

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

2016-10-12 Thread Matthew Seaman
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

2016-10-12 Thread Kubilay Kocak
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

2016-10-12 Thread Kubilay Kocak
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

2016-10-12 Thread portscout
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

2016-10-12 Thread Julian Elischer

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

2016-10-12 Thread Vlad K.

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

2016-10-12 Thread Andrea Venturoli

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

2016-10-12 Thread Matthieu Volat
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