[debpool] Re: Should Allow_Version distinguish different archs?

[Free Ekanayaka]

|--==> Magnus Holmgren writes:

  MH> On Tuesday 24 April 2007 11:17, Free Ekanayaka wrote:
  >>|--==> Magnus Holmgren writes:
  MH> The $VersionDBs have to use $arch in the keys, and Set_Versions(),
  MH> Get_Version(), and Allow_Version() has to take it into consideration.
  >>I'm on MH> it, but I have to check out a new copy to be able to commit just
  >>that change MH> to Packages.pm, and also I don't know if it's worth it if
  >>the database is MH> going to change radically.
  >>
  >>Well, it's something that is probably needed to get true multi-arch
  >>support, unless we decided to "support" this feature through the
  >>rollback option, which is bit hacky.

  MH> There's an additional issue: DebPool can't handle binNMUs, AFAICT. Those have 
  MH> the property that the Version field in the .changes file (the "meta version") 
  MH> is greater than the source version, and typically equal to the binary version 
  MH> (although binaries can, as you know, have completely different version 
  MH> numbers) of that particular arch. The thing is that there can be an arbitrary 
  MH> number of binNMUs for each arch: for example, two rebuilds on i386, +b1 and 
  MH> +b2, then a rebuild on amd64, also +b1. This means that the "meta version" 
  MH> can go up and down, and we should *not* implement special handling for +bN 
  MH> version numbers - that's strictly dpkg-genchanges's business. What the heck 
  MH> is a "meta version" anyway? I say we get rid of it.

Actually I didn't have binNMUs in mind, but simply binary uploads, so
the situation is much simpler and very common.

I typically build packages both for amd64 and i386, built from the
same source package (hence both binary builds get same Version:
field), and if debpool has multi-arch support I'd just expect to be
able to upload both my amd64 and my i386 builds.

At the moment this is possible only by setting the rollback option, to
avoid the check in Allow_Version.

Ciao,

Free