Sorry to jump in late.
On Saturday 04 April 2009 16:13:22 Chris Whitehouse wrote:
pkg_add somewhat addresses this but it doesn't work quite as well as
ports because of possible version mismatches.
The suggestion below is not aimed at servers because they have
completely different
Bob Johnson wrote:
- reduced energy use for everyone.
I think the difference in energy use would be so small as to be
pointless. If I have a system that consumes 75 kilowatt hours per
month, and I spend an extra 0.05 kilowatt hour per month updating
ports, is the difference (less than 1/10
Bob Johnson wrote:
On 4/8/09, Jonathan McKeown j.mcke...@ru.ac.za wrote:
On Tuesday 07 April 2009 23:35:03 Bob Johnson wrote:
On 4/4/09, Chris Whitehouse cwhi...@onetel.com wrote:
The drawback I can see is the disk space required to keep several
generations
of packages online - if the
On Fri, 10 Apr 2009 15:25:13 +0100, Chris Whitehouse cwhi...@onetel.com wrote:
Is there a quick way to find out how big are the tarballs without
downloading them all or adding them up one by one?
I think it's possible to obtain an FTP ls listing and then use
awk to get the column with the size
Polytropon wrote:
On Fri, 10 Apr 2009 15:25:13 +0100, Chris Whitehouse cwhi...@onetel.com wrote:
Is there a quick way to find out how big are the tarballs without
downloading them all or adding them up one by one?
I think it's possible to obtain an FTP ls listing and then use
awk to get the
Ok here's an improved description of how it works. The key to the whole
thing is the snapshot of the ports tree. Everything else follows from that.
Build process:
A predetermined set of packages is built from a ports tree. The most
benefit comes with packages which would acceptable for use with
On Wednesday 08 April 2009 21:24:00 Bob Johnson wrote:
PC-BSD seems to already keep up-to-date binary packages of their
applications. Do they accomplish that by only offering a small subset
of the full ports collection?
Yes - have a look at http://www.pbidir.com/. I installed PC-BSD on a spare
I'd like to use this opportunity to generally support this and any
other ideas taking direction of making binary installs and upgrades
easier and more manageable. I recognize the need for people to
configure custom options and compile from ports (that is why any new
system *must* be compatible
On Thu, 9 Apr 2009 09:16:12 +0200, Jonathan McKeown j.mcke...@ru.ac.za wrote:
Yes - have a look at http://www.pbidir.com/. I installed PC-BSD on a spare
machine to investigate it. The first three ports/metaports I tried to install
after completing the base setup were emacs, TeTeX and the Psi
...@freebsd.org] On Behalf Of n j
Sent: Thursday, April 09, 2009 3:15 AM
To: User Questions
Subject: Re: new package system proposal
I'd like to use this opportunity to generally support this and any
other ideas taking direction of making binary installs and upgrades
easier and more manageable. I
/security/krb5.
-Original Message-
From: Gary Gatten
Sent: Thursday, April 09, 2009 10:46 AM
To: 'n j'; User Questions
Subject: RE: new package system proposal
I haven't worked with *nix os's as much as FreeBSD - Well, maybe
different flavors of SCO but as far as installing apps and what
AM
To: 'n j'; 'User Questions'
Subject: RE: new package system proposal
This is the kinda B$ I'm talking about. Trying to install krb5 from
ports, and after 2 hours (or more) of finding and compiling dependencies
and whatever else make does - it aborts! WTF!!! I'm sure when I try
to remove
Nino wrote:
I'd like to use this opportunity to generally support this and any
other ideas taking direction of making binary installs and upgrades
easier and more manageable.
You may be interested to read
http://www.lpthe.jussieu.fr/~talon/freebsdports.html
and to consider playing with
On Tuesday 07 April 2009 23:35:03 Bob Johnson wrote:
On 4/4/09, Chris Whitehouse cwhi...@onetel.com wrote:
Hi all
[...]
My suggestion is to start with a ports tree that is fixed in time. Make
that ports tree available as part of this package system and compile a
typical desktop set of
On 4/8/09, Jonathan McKeown j.mcke...@ru.ac.za wrote:
On Tuesday 07 April 2009 23:35:03 Bob Johnson wrote:
On 4/4/09, Chris Whitehouse cwhi...@onetel.com wrote:
Hi all
[...]
My suggestion is to start with a ports tree that is fixed in time. Make
that ports tree available as part of this
Chris Whitehouse wrote:
You've suggested solutions to a couple of Polytropon's objections, thank
you. Do you think there is anough mileage in my suggestion to make it
worth putting in front of some ports people? What would have
to happen to take it forward? I could rewrite the proposal more
Matthew Seaman wrote:
Chris Whitehouse wrote:
You've suggested solutions to a couple of Polytropon's objections,
thank you. Do you think there is anough mileage in my suggestion to
make it worth putting in front of some ports people? What would have
to happen to take it forward? I could
On 4/4/09, Chris Whitehouse cwhi...@onetel.com wrote:
Hi all
[...]
My suggestion is to start with a ports tree that is fixed in time. Make
that ports tree available as part of this package system and compile a
typical desktop set of ports, particularly choosing ones which are large
or have
Hmm Polytropon you seem to be dismissing my idea with minor examples.
I am convinced it could work, and that people would appreciate it. I've
tried to answer your points, apologies if I have misunderstood any of them.
Polytropon wrote:
Compiling applications in general will lead you into one
Matthew Seaman wrote:
Polytropon wrote:
Compiling applications in general will lead you into one
main problem: Many ports have different options that need
to be set at compile time. For a set of n options, 2^n
packages would be created, if I consider the WITH_SOMETHING
options only.
One
On Mon, 06 Apr 2009 22:48:01 +0100, Chris Whitehouse cwhi...@onetel.com wrote:
Hmm Polytropon you seem to be dismissing my idea with minor examples.
Actually not, because I'm a big fan of pkg_add -r. :-)
I honestly run older machines, the oldest one is a P1 150MHz with
128 MB EDO-RAM where
per...@pluto.rain.com wrote:
Chris Whitehouse cwhi...@onetel.com wrote:
My suggestion is to start with a ports tree that is fixed in time.
Make that ports tree available as part of this package system and
compile a typical desktop set of ports ...
Isn't this exactly what is currently done as
Hi all
I was thinking about the waste of energy and time involved in lots of
people around the world all compiling the same code such as openoffice,
firefox, kde etc and wondering how the package system could be improved.
Ports is rightly a flagship element of FreeBSD. The benefit is
Compiling applications in general will lead you into one
main problem: Many ports have different options that need
to be set at compile time. For a set of n options, 2^n
packages would be created, if I consider the WITH_SOMETHING
options only.
One example is mplayer. Its various options select
Polytropon wrote:
Compiling applications in general will lead you into one
main problem: Many ports have different options that need
to be set at compile time. For a set of n options, 2^n
packages would be created, if I consider the WITH_SOMETHING
options only.
One example is mplayer. Its
Chris Whitehouse cwhi...@onetel.com wrote:
My suggestion is to start with a ports tree that is fixed in time.
Make that ports tree available as part of this package system and
compile a typical desktop set of ports ...
Isn't this exactly what is currently done as part of a release? The
ports
26 matches
Mail list logo
