Re: Alternative: Source-Centric Approach [w/code]
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 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?
You have a point here.
> 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.
True.
> > > * 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? :-)
I see that we can have a more flexible approach for releases.
Full support (i386, etc):
all packages are supported (debs, security updates etc).
Basic support (some other arches):
installer, base and essential pacakges built, maybe with some more
things. The rest is up to the user to compile, maybe using something
similar that you have here.
No support (sh, hurd...):
Well some things may work but that is nothing that Debian guarantees. :)
This is just what comes to mind. I'm not saying we should do this, and
not even that I want it to. It was just an idea, and very similar to yours.
Regards,
// Ola
> -- John
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Annebergsslingan 37 \
| opal@lysator.liu.se 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: