[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A better recompile process? Was: Re: testing, unstable, and dependencies



Hello

On Mon, Feb 10, 2003 at 09:18:23AM +1100, Brian May wrote:
> On Sun, Feb 09, 2003 at 12:31:55PM +0100, Ola Lundqvist wrote:
> > Before I answer I have to know one more thing. Is all packages recompiled
> > before they enter unstable or is that just for testing?
> > 
> > If they are not recompiled that will not be a problem because that they
> > are tested becuase people tend to use unstable (at least people like
> > me).
> > 
> > If all packages are recompiled before entering unstable that is a
> > problem. If so we have to tag them differently depending on if
> > they are rebuilt or not.
> 
> I may have misunderstood you question.
> 
> When you upload a package to Debian, you upload the source code, plus
> one compiled version to unstable.
> 
> Debian autobuilders will then build the source code for all other
> architectures, and puts the result in unstable.
> 
> The code is not recompiled again, even if it goes into testing or
> stable.

Thanks for the information. I tried to figure out how quinn-diff
and the autobuilders worked and found out exactly what you told me
now. Good to get that verified. :) The reason why I become uncertain
was that I earlier got the impression that all packages got recompiled.

> Which perhaps is another idea, that is that code should be compiled
> for unstable when it enters unstable, and it should be compiled for
> testing when it enters testing.

That is another idea. They have to be named differently (deb file name)
and this do not work really well with package pools, or?

> However, implementing this might be complicated if you don't want a
> package to enter testing until it has been built on all architectures
> for testing. You would need some sort of holding area between unstable
> and testing where packages go before the testing version is completely
> built.

Or simply name the .deb file differently for different releases. I do not
know if this is a good thing to do, though.

> When a new major library version enters testing, the applications will
> depend on the old one still and may have to get rebuilt. It is possible
> that at least some of these will break due to incompatabilities.
> 
> There might be other issues here too, but I haven't but much
> consideration into it.

I do not think building against woody is a big issue becuase you can
always make version dependencies.

One other problem is that people have to run testing to make
uploads that can go into testing at least when there are problems
with the packages that it depends on.

I'll think about a bit more and try to get a good solution to
this problem.

Regards,

// Ola

> -- 
> Brian May <bam@debian.org>
> 
> 
> -- 
> 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: