Re: harder and harder to avoid pkg

2016-10-17 Thread Torsten Zuehlsdorff
On 16.10.2016 05:16, Alfred Perlstein wrote: Has anyone actually looked/asked how other OS's solve this problem? Yes, for various linux distributions. This provided me with so many reasons to stay and work with the ports-tree. I too found "xxx-dev" vs "xxx-lib" annoying until I realized

Re: harder and harder to avoid pkg

2016-10-15 Thread Alfred Perlstein
Has anyone actually looked/asked how other OS's solve this problem? I too found "xxx-dev" vs "xxx-lib" annoying until I realized how clean it actually is. We should definitely be surveying the landscape before rolling our own NIH solution. -Alfred On 10/14/16 8:30 AM, Julian Elischer

Re: harder and harder to avoid pkg

2016-10-14 Thread Dave Horsfall
On Fri, 14 Oct 2016, David Demelier wrote: > It's not writing a port that is complicated, it's the whole > infrastructure. You should see the Macports infrastructure... Fairly easy for the end user, but those developers sweat blood to make it so. -- Dave Horsfall DTM (VK2KFU) "Those who

Re: harder and harder to avoid pkg

2016-10-14 Thread Julian Elischer
On 14/10/2016 4:27 AM, Matthieu Volat wrote: On Fri, 14 Oct 2016 13:05:35 +0200 David Demelier wrote: 2016-10-14 11:22 GMT+02:00 Baptiste Daroussin : It is imho doable in both sides. We could imagine tagging the plist/manifest so pkg can allow a

Re: harder and harder to avoid pkg

2016-10-14 Thread Matthieu Volat
On Fri, 14 Oct 2016 13:05:35 +0200 David Demelier wrote: > 2016-10-14 11:22 GMT+02:00 Baptiste Daroussin : > > It is imho doable in both sides. > > > > We could imagine tagging the plist/manifest so pkg can allow a user to > > install > > only the

Re: harder and harder to avoid pkg

2016-10-14 Thread Kurt Jaeger
Hi! > > This is an appliance class machine. It has 2G of storage and that has > > to include 2 copies for the OS so we can ping-pong for upgrades. > > I can get > 2GB CPU cache per system (spread over 8+ sockets) these > days. Is it really reasonable to expect port maintainers to take up the

Re: harder and harder to avoid pkg

2016-10-14 Thread Jan Bramkamp
On 14/10/2016 09:39, Julian Elischer wrote: On 13/10/2016 10:33 AM, RW via freebsd-ports wrote: 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

Re: harder and harder to avoid pkg

2016-10-14 Thread David Demelier
2016-10-14 11:22 GMT+02:00 Baptiste Daroussin : > It is imho doable in both sides. > > We could imagine tagging the plist/manifest so pkg can allow a user to install > only the things tagged as runtime for exemple which would do the job. for what > Julian is asking for beside

Re: harder and harder to avoid pkg

2016-10-14 Thread Matthew Seaman
On 10/14/16 10:22, Baptiste Daroussin wrote: > We could imagine tagging the plist/manifest so pkg can allow a user to install > only the things tagged as runtime for exemple which would do the job. for what > Julian is asking for beside adding lots of complexity pkg(8) and adding a > nightmare in

Re: harder and harder to avoid pkg

2016-10-14 Thread Baptiste Daroussin
On Fri, Oct 14, 2016 at 09:54:07AM +0200, Mathieu Arnold wrote: > Le 14/10/2016 à 09:34, Julian Elischer a écrit : > > On 13/10/2016 5:42 AM, David Demelier wrote: > >> 2016-10-12 10:04 GMT+02:00 Andrea Venturoli : > >>> On 10/12/16 09:24, Matthieu Volat wrote: > >>> > And

Re: harder and harder to avoid pkg

2016-10-14 Thread Mathieu Arnold
Le 14/10/2016 à 09:34, Julian Elischer a écrit : > On 13/10/2016 5:42 AM, David Demelier wrote: >> 2016-10-12 10:04 GMT+02:00 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

Re: harder and harder to avoid pkg

2016-10-14 Thread Julian Elischer
On 13/10/2016 10:33 AM, RW via freebsd-ports wrote: 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.

Re: harder and harder to avoid pkg

2016-10-14 Thread Julian Elischer
On 13/10/2016 5:42 AM, David Demelier wrote: 2016-10-12 10:04 GMT+02:00 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,

Re: harder and harder to avoid pkg

2016-10-14 Thread David Demelier
2016-10-14 8:14 GMT+02:00 Loïc BLOT : > FreeBSD ports are complicated ? > Does someone of you tryed to do a Debian package, it's even more > complicated as you should modify many path, split package in multiple > packages, do the service engineering with systemV or

Re: harder and harder to avoid pkg

2016-10-14 Thread Loïc BLOT
FreeBSD ports are complicated ? Does someone of you tryed to do a Debian package, it's even more complicated as you should modify many path, split package in multiple packages, do the service engineering with systemV or systemD, etc ? -- Best regards, Loïc BLOT, UNIX systems, security and

Re: harder and harder to avoid pkg

2016-10-13 Thread RW via freebsd-ports
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

Re: harder and harder to avoid pkg

2016-10-13 Thread Miroslav Lachman
David Demelier wrote on 2016/10/13 14:42: 2016-10-12 10:04 GMT+02:00 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,

Re: harder and harder to avoid pkg

2016-10-13 Thread David Demelier
2016-10-12 10:04 GMT+02:00 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

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,

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

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 -

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 >>

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 >>

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

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

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

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 >

Re: harder and harder to avoid pkg

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

Re: harder and harder to avoid pkg

2016-10-11 Thread Alfred Perlstein
I feel like creative use of run/build-depends would work but I'm a bit tired now. Well you probably don't want any or near zero deps down a library depends path. Sent from my iPhone > On Oct 11, 2016, at 10:08 PM, Julian Elischer wrote: > >> On 11/10/2016 5:34 PM, Alfred

Re: harder and harder to avoid pkg

2016-10-11 Thread Julian Elischer
On 11/10/2016 5:34 PM, Alfred Perlstein wrote: Make a slave port with an abbreviated pkg-plist bruh. ;) yeeess, good idea, but that won't satisfy the dependency requirements of other packages... you need to fool other packages, and that's the hard part. The way to do this is I think for pkg to

Re: harder and harder to avoid pkg

2016-10-11 Thread Alfred Perlstein
Make a slave port with an abbreviated pkg-plist bruh. ;) -Alfred On 10/11/16 11:59 AM, 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

Re: harder and harder to avoid pkg

2016-10-11 Thread Julian Elischer
On 11/10/2016 12:51 PM, olli hauer wrote: On 2016-10-11 20: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

Re: harder and harder to avoid pkg

2016-10-11 Thread Mathieu Arnold
Le 11/10/2016 à 20:59, Julian Elischer a écrit : > 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

Re: harder and harder to avoid pkg

2016-10-11 Thread Roger Marquis
On Tue, 11 Oct 2016, Julian Elischer wrote: *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 We do something similar using prebuilt (pkg fetch) or locally built (make

Re: harder and harder to avoid pkg

2016-10-11 Thread olli hauer
On 2016-10-11 20: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.