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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)



Luk Claes <luk@debian.org> writes:

> Goswin von Brederlow wrote:
>> Adeodato Simó <dato@net.com.org.es> writes:
>> 
>>> * Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]:
>
>>> Mark Hymers has talked about providing a mechanism to ensure source
>>> packages stay on the pool when other stuff has been built from them (eg.
>>> kernel module packages). With this, ia32-libs could become a small
>>> source package containing scripts that would download the necessary
>>> binary packages at build time, and would encode in a header the employed
>>> versions; then, source for those versions would not be removed from the
>>> pool.
>> 
>> Buildds don't have internet access in their build
>> environment. ia32-libs may not download anything at build time. Plus
>> rebuilding would give widely unreproducible results.
>
> AFAIK you're talking about 2 architectures, so building them in another
> way than on the buildds should not be hard.
>
> I guess you mean unpredictable instead of unreproducible as building
> with the same versions as mentioned in the build log should be
> reproducible or ia32-libs better just gets removed from the archive
> altogether... Why would it be unpredictable, what issues do you see?

unpredictable yes. The problem is that downloading packagescan fail
for any number of reasons and gets different versions between
builds. Verry unpredictable.

And until there is a way for a deb to force DAK to keep other source
packages available ia32-libs would quickly violate the GPL (binary
without source). I don't see that magic feature comming anytime soon
given how slow DAK changes. Till it does the above is just not an option.

>> Currently the size makes regular uploads too costly imho. And the
>> security team is still not supporting ia32-libs. I even did prepare an
>> security upload for etch last year that they only had to sponsor but
>> never heard back from the team.
>
> A good reason to not just shoot any proposal to make that easier IMHO.
>
> Cheers
>
> Luk

MfG
        Goswin


Reply to: