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 buildable
> on the architecture without building it? And if you have built it why not
Well, how do you make sure that the package is runnable on the
architecture without running it?
Yes, it's a bit less testing, but OTOH, if nobody notices that the
package can't be installed, that says something.
> > The problem of syncing with testing is also reduced; now we need only
> > make sure base is synced across archs.
>
> What you really are saying that for some arches we only support base
> and essential (and some more). Everything else is provided as source debs
> and not supported, even if it might work. I mean the source is available
> currently and the only thing you say is that we should only build some
> parts of that port.
No, I'm not commenting on suport. I'm just commenting on what .debs are
out there and autobuilt. I want everything else to stay the same.
However, the job of supporting n archs for things like security updates
is reduced to the job of supporting 1 source package.
> > * Difficulty of dealing with dependency loops
> > (possible solution: include one .deb from each loop in the dist)
> >
> > * Disk space requirements to build packages
>
> * Not possible to tell if a package is buildable on a specific arch or not.
^ in advance
Yes, that is a downside.
> > So, what do you think? Could this work?
>
> Nice idea, but I do not really see the benefit, more than on ftp disk space
> and security update speed.
Also with the testing synchronization. But then, these three are the
main problems we've been told about, right? :-)
-- John
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
