Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Peter Samuelson <peter@p12n.org> writes:
> [Adeodato Simó]
>> 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.
>
> I understand different binary packages from a single source package do
> not have to share a single version string - so could ia32-libs be done
> in such a way that each binary package gets a version number related to
> the "real" source package it is built from? ia32-libs itself could
> append a sort of 'micro-epoch' value that would only change when
> substantive changes are made to how the binary packages are built.
Currently ia32-libs source builds one ia32-libs.deb. Not split up per
binary package it contains.
> Thus when you binNMU ia32-libs in order to pick up a newer library
> upload, all the libraries that have not changed will not get new
> version numbers and nobody would need to upgrade them. But would this
> situation (trying to upload a version that is already present) confuse
> dak? I presume dak will just ignore that binary, yes?
The problem isn't the really the user needing to downlod 40MB for an
update. The problem I see is having to upload 600MB and mirror
that.
And yes, uploading a new source that builds a deb with the same
version as the last source will cause DAK to reject the upload.
For your idea to work the ia32-libs source has to be split. That would
allow fine grained updates but still have the problem of source
duplication and prebuild binaries. Ftpmaster didn't want that any more
than ia32-libs now.
MfG
Goswin
Reply to: