Re: [PATCHv3] dpkg-base: derive "Package" and "Architecture" from .deb in cleanup

[Henning Schild <henning.schild@siemens.com>]

Am Thu, 28 Mar 2019 12:03:28 +0100
schrieb Baurzhan Ismagulov <ibr@radix50.net>:

> Hello Henning,
> 
> On Thu, Feb 21, 2019 at 04:56:34PM +0100, Henning Schild wrote:
> > If
> > your recipe created such a package it could never be cleaned
> > because it was added to all the archs of the repo, and later
> > cleaned only from one. Now if that package changes because you are
> > still working on the recipe, adding the package again would cause
> > checksum mismatches for all but the current architecture.  
> 
> IMHO, it's unclear who is "you" in the commit message. I'd suggest to
> reword in a more neutral form, e.g.:
> 
> -your recipe created such a package it could never be cleaned because
> it +a recipe created such a package it could never be cleaned because
> it ...
> -Now if that package changes because you are still working on the
> recipe, +Now if that package changes because one is still working on
> the recipe,
> 

Ok, you or Maxim can fix that on merge. I hope it is clear who you
is ;). I will be out of office for two weeks, if you dont the patch
will have to keep waiting.

> > +            p=$( dpkg-deb --show --showformat '${Package}' ${d} )
> > +            a=$( dpkg-deb --show --showformat '${Architecture}'
> > ${d} )  
> 
> Thanks, this is better than sed.
> 
> 
> > +            reprepro -b ${REPO_ISAR_DIR}/${DISTRO} \
> > +                     --dbdir ${REPO_ISAR_DB_DIR}/${DISTRO} \
> > +                     -C main ${aarg} \
> > +                     remove ${DEBDISTRONAME} \
> > +                     ${p}  
> 
> How can one reproduce the problem? I'd like to understand the cause
> because at the first glance I'd think an _all.deb package should land
> in the pool only once.

That is written in the commit message.

A deployment of "all" will not deploy one .deb of arch "all" but it
will deploy n .debs of all the archs enabled in the repo.
So on deploy of "all" from arm into a "arm, arm64, x86" repo you will
get three copies. The next deploy from x86 will write all three again,
same for arm64. But they are all the same and just get written 3 times.

But a clean of "-A all" is a no-op since that arch does not exist. That
clean will not actually clean up the deployment correctly. And
subsequent changes deploys will run into problems.

The easiest way to just get to the "broken" clean is to build an "all"
package. Deploy it and repo_clean it, you should still see it in the
other archs ...
If you still need to see more change anything in the recipe keeping all
of ${P} the same, the deploy should fail.

That also means we must never use the repo while another arch deploys
into it because we get sharing over "all". That is a severe problem if
you have "all" packages and use multiconf. My suggestion would be to
avoid both ;). However that issue should be documented or fixed for
people who care about multiconfig ;).

> In general, subtle stuff like this should ideally be covered with a
> test case.

I agree and i am the one constantly asking for tests. All the
rebuilding patches that got merged so far are not covered by tests. I
guess some tests that trigger partial rebuilds would be needed. But
that is probably out of scope of this patch.

Yes we need tests for new features. Tests for corner-case bugfixes ...
would be handy but holding back bug-fixes for it?

Henning

> 
> With kind regards,
> Baurzhan.
>