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 how
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 wrote
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 don
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 user to install
only the things tagged as runt
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 things tagged as runtime for exemple which would
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
>
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 on
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 adding lots of complex
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 t
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 GNU/Linuxes can be a
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
(which sometimes really
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. Ho
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, describe
to people how
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 systemD, etc ?
It's not writing
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 network
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
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, describe
to people how the
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 to build your softw
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
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 def
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
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
>> bina
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
>> bina
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
mani
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
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 p
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 so
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
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 Perlstein wrote:
>>
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
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 increased.
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 a
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 situations.
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 package)
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.
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 Li
36 matches
Mail list logo