[Piuparts-devel] Merged /usr - supported in stretch?

[Holger Levsen]

Hi,

On Wed, Mar 22, 2017 at 12:02:50AM +0200, Adrian Bunk wrote:
> (everything below is AFAIK and IMHO, please correct any mistakes)
> (Andreas added due to piuparts, see 4.)

please dont mail anbe at debian.org if you want to reach the piuparts
maintainers. Please use piuparts-devel at lists.alioth.debian.org instead.
(cc: adjusted)

> 4. Automated testing
> 
> I do not know what kind of automated testing has already been done,
> but there are at least 4 areas where piuparts might be able to find
> problems with merged /usr:

there is #848968: "piuparts.debian.org: should have a sid-merged-usr test
once buster development has begun" and given that usermerge wont be the
default for stretch, I think this is still sensible, so that we can now 
focus on issues that effect stretch in its default configuration…

> a) testing that all packages in stretch can be installed and uninstalled

this can be done by piuparts (easily, for some values of it), so we could
*maybe* still do it…

> b) automated testing that there are no problems caused by /bin/foo and 
>    /usr/bin/foo shipped in different packages

this cannot be done by piuparts, really.

> c) testing that the Conflicts of usrmerge cover all packages in jessie
>    that must be upgraded when installing the usrmerge package 

besides that I wouldnt do this for jessie if we make usrmerge the default in
buster, it's also not trivial to do this, because usrmerge is not revertable,
so this will not work:

- install package on stretch
- upgrade to buster
- enable usrmerge
- remove package from stretch
- compare the diffs, as you know compare stretch with usrmerge against stretch without usrmerge.

> d) searching for packages in previous releases that are no longer in
>    stretch and that break usrmerge, to have them added to the usrmerge 
>    Conflicts

how would you do that in an automated fashion?

> It would be beneficial for users upgrading to stretch if someone would 
> cover such issues with piuparts testing.
 
It would be beneficial if more people would be working on piuparts testing.


-- 
cheers,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/piuparts-devel/attachments/20170322/e62ea927/attachment.sig>