"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
> > 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 so
"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 a
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 .
> > 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 G
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 extre
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 i
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, bui
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
>
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 m
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
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 P
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 wo
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: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
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 pa
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 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.
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? Bec
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 gi
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 prod
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 ]
>
> >
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 ke
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
>
> The
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 instal
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
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, ar
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
> resource
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 Pawłaszek
"You will never see me fall from grace..." [KoRn]
* 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: lo
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, th
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
4)
32 matches
Mail list logo
