Freddie Unpenstein [EMAIL PROTECTED] writes:
I'm wondering, what happens if you want to install MOST of the deps
from source? Wouldn't it be better to have apt-build (using the
official apt algorithms) ask on a dep-by-dep basis whether you
want it compiled from source or installed from a
Freddie Unpenstein [EMAIL PROTECTED] writes:
Your priority are your users, and if Debian has decided to focus
only on some key architectures it would be the best for them to
help them switching to Gentoo instead of hacking Debian to become
some cheap Gentoo clone for most architectures.
I'm wondering, what happens if you want to install MOST of the deps
from source? Wouldn't it be better to have apt-build (using the
official apt algorithms) ask on a dep-by-dep basis whether you
want it compiled from source or installed from a binary?
Which is basically what sourcerer
On Tue, Mar 15, 2005 at 11:25:23AM -0600, John Goerzen wrote:
I'm throwing out a different idea,
I propose that we split things along these lines: binary+source (B+S)
archs and source-only (SO) archs.
SO archs will be handled exactly like we do now, EXCEPT that we will
not distribute .debs
Your priority are your users, and if Debian has decided to focus
only on some key architectures it would be the best for them to
help them switching to Gentoo instead of hacking Debian to become
some cheap Gentoo clone for most architectures.
I don't view this as being a cheap Gentoo
On Fri, Mar 18, 2005 at 07:39:06PM -0600, Gunnar Wolf wrote:
Matthias Urlichs dijo [Tue, Mar 15, 2005 at 11:14:50PM +0100]:
It won't work that well for slower architectures, for the very simple
reason that compiling everything would take a long time.
m68k (as the admittedly extreme
Matthias Urlichs dijo [Tue, Mar 15, 2005 at 11:14:50PM +0100]:
It won't work that well for slower architectures, for the very simple
reason that compiling everything would take a long time.
m68k (as the admittedly extreme example) doesn't have ten buildd boxes
just because we feel like it.
Op di, 15-03-2005 te 11:25 -0600, schreef John Goerzen:
As I have been reading the discussions about the SCC proposal for
etch, it seems that these are the main problems:
1) Difficulty with, and speed of, buildd systems
2) Difficulty of syncing testing across all archs given #1
3)
On Wed, Mar 16, 2005 at 02:30:29PM +0100, Wouter Verhelst wrote:
...
Also it wouldn't help on slower architectures. People usually decline
installing NetBSD on m68k (even if that's possible) when it takes two
weeks to make the system useful, simply because everything needs to be
compiled
Hello
On Tue, Mar 15, 2005 at 04:10:17PM -0600, John Goerzen wrote:
On Tue, Mar 15, 2005 at 10:45:45PM +0100, Ola Lundqvist wrote:
Hello
distribute for a SO arch). Anything past that is there just for QA
purposes -- to make sure packages are buildable on these archs, and
would be
Hello
On Wed, Mar 16, 2005 at 02:30:29PM +0100, Wouter Verhelst wrote:
Op di, 15-03-2005 te 11:25 -0600, schreef John Goerzen:
As I have been reading the discussions about the SCC proposal for
etch, it seems that these are the main problems:
1) Difficulty with, and speed of, buildd
As I have been reading the discussions about the SCC proposal for
etch, it seems that these are the main problems:
1) Difficulty with, and speed of, buildd systems
2) Difficulty of syncing testing across all archs given #1
3) Difficulty getting security releases out in time, given slow archs
On Tue, Mar 15, 2005 at 11:25:23AM -0600, John Goerzen wrote:
So, what do you think? Could this work?
I like the idea a lot. What I'd like to see is a way to do a
cross-platform build for the small system targets. I do a lot of ARM
work: low-performance, resource limited targets.
Frankly,
* Marc Singer ([EMAIL PROTECTED]) wrote:
On Tue, Mar 15, 2005 at 11:25:23AM -0600, John Goerzen wrote:
So, what do you think? Could this work?
I like the idea a lot. What I'd like to see is a way to do a
cross-platform build for the small system targets. I do a lot of ARM
work:
On Tuesday 15 of March 2005 18:25, John Goerzen wrote:
[...]
More on srcinst:
[...]
So, what do you think? Could this work?
What's a difference between srcinst and apt-build ? ;-)
Regards.
--
Lech Karol Pawaszek ike
You will never see me fall from grace... [KoRn]
On Tue, Mar 15, 2005 at 12:42:54PM -0500, Stephen Frost wrote:
- Mirror only the popular archs.
- Support buildds for stable-enough archs that run them.
- Try to include everything in a release, but drop archs more
quickly than has been done in the past if there's a lack of
resources,
Hi, John Goerzen wrote:
1) Difficulty with, and speed of, buildd systems
2) Difficulty of syncing testing across all archs given #1
2a) Bugs on small arch which blocks testing migration of big arch
There are not many people who can do in-depth debugging on most small
architectures,
On Tue, Mar 15, 2005 at 06:42:32PM +0100, Lech Karol Paw?aszek wrote:
On Tuesday 15 of March 2005 18:25, John Goerzen wrote:
[...]
More on srcinst:
[...]
So, what do you think? Could this work?
What's a difference between srcinst and apt-build ? ;-)
egrep 'apt-get.*install' apt-build |
On Tue, Mar 15, 2005 at 11:25:23AM -0600, John Goerzen wrote:
...
SO archs will be handled exactly like we do now, EXCEPT that we will
not distribute .debs for most packages. I expect that we will
distribute .debs for base and build-essential, mainly -- the minimum
someone needs to install a
On Tue, Mar 15, 2005 at 06:57:00PM +0100, Matthias Urlichs wrote:
Hi, John Goerzen wrote:
1) Difficulty with, and speed of, buildd systems
2) Difficulty of syncing testing across all archs given #1
2a) Bugs on small arch which blocks testing migration of big arch
There are not many
On Tue, Mar 15, 2005 at 07:46:23PM +0100, Adrian Bunk wrote:
don't handle deps at all)
...
So, what do you think? Could this work?
Yes, this could work.
That's what Gentoo is good at.
[ snip ]
Your priority are your users, and if Debian has decided to focus only on
some key
On Tue, Mar 15, 2005 at 02:24:01PM -0600, John Goerzen wrote:
On Tue, Mar 15, 2005 at 07:46:23PM +0100, Adrian Bunk wrote:
don't handle deps at all)
...
So, what do you think? Could this work?
Yes, this could work.
That's what Gentoo is good at.
[ snip ]
Your priority are
On Tue, Mar 15, 2005 at 12:53:31PM -0800, Marc Singer wrote:
Yes, but I hope that this proposal, or other suggestions, can help us
avoid dropping ports. This specific proposal, for instance, is meant to
provide us with a way forward that addresses the main concerns while
still producing a
Hello
On Tue, Mar 15, 2005 at 11:25:23AM -0600, John Goerzen wrote:
As I have been reading the discussions about the SCC proposal for
etch, it seems that these are the main problems:
1) Difficulty with, and speed of, buildd systems
2) Difficulty of syncing testing across all archs given
Ola Lundqvist on 2005-03-15 22:45:45 +0100:
This is the problem. How do you make sure that the package is
buildable on the architecture without building it? And if you have
built it why not just add it to the archives. :) So you still need a
buildd. :(
Why not add it to the archives?
On Tue, Mar 15, 2005 at 04:55:08PM -0500, Alec Berryman wrote:
Ola Lundqvist on 2005-03-15 22:45:45 +0100:
This is the problem. How do you make sure that the package is
buildable on the architecture without building it? And if you have
built it why not just add it to the archives. :) So
On Tue, Mar 15, 2005 at 10:45:45PM +0100, Ola Lundqvist wrote:
The speed of buildd systems mostly becomes irrelevant. They will
still have to keep up with base (the set of .debs that we do
distribute for a SO arch). Anything past that is there just for QA
purposes -- to make sure
On Tue, Mar 15, 2005 at 10:45:45PM +0100, Ola Lundqvist wrote:
Hello
distribute for a SO arch). Anything past that is there just for QA
purposes -- to make sure packages are buildable on these archs, and
would be optional.
This is the problem. How do you make sure that the package is
On Tue, Mar 15, 2005 at 11:01:06PM +0100, Adrian Bunk wrote:
On some mirrors?
- Not all mirrors have to mirror all ports.
The mirroring part of the proposal is effectively just a proposal to
rearrange the archive in order to make this easy for mirror admins.
--
You grabbed my hand and we
Hi, John Goerzen wrote:
This specific proposal, for instance, is meant to
provide us with a way forward that addresses the main concerns while
still producing a quality, usable result for our users.
It won't work that well for slower architectures, for the very simple
reason that compiling
On Tue, Mar 15, 2005 at 11:14:50PM +0100, Matthias Urlichs wrote:
Hi, John Goerzen wrote:
This specific proposal, for instance, is meant to
provide us with a way forward that addresses the main concerns while
still producing a quality, usable result for our users.
It won't work that
Mark Brown schrieb:
On Tue, Mar 15, 2005 at 11:01:06PM +0100, Adrian Bunk wrote:
On some mirrors?
- Not all mirrors have to mirror all ports.
The mirroring part of the proposal is effectively just a proposal to
rearrange the archive in order to make this easy for mirror admins.
[-snip-]
[EMAIL
32 matches
Mail list logo
