[Piuparts-devel] piuparts for jessie
Andreas Beckmann
anbe at debian.org
Fri Nov 21 17:12:03 UTC 2014
On 2014-11-21 17:11, Holger Levsen wrote:
> On Freitag, 21. November 2014, Andreas Beckmann wrote:
>> what do we need to fix in piuparts for jessie?
>
> its not broken, or? which bugs do you consider as blocker / must fixes?
testing should be testing, at least as long as jessie==stable
Or we should *not* ship that alias enabled in a stable release.
>> In addition to develop in git:
>
> I fear there is probably too much in the develop branch already to get a
> freeze exception.
I think the init system related things could only be done properly after
that had settled ...
Then there is syncing with adequate in jessie ...
There is only one feature (post_chroot_unpack) which at least did not
break piuparts.d.o in a few thousand packages.
> my plan was actually to support jessie via jessie-backports
> like we (I) do for wheezy atm.
That's fine for future development, but at least the initial version
should be working reliably with the default init change and the default
settings.
>> * if eatmydata does not get fixed in time, we could just turn it off by
>> default (and add a --eamydata option, keeping --no-eatmydata unmodified)
>
> what's the eatmydata bug? (I'm aware about the piuparts bug about the issue,
> but that bug is exactly that, assigned to piuparts.)
added a blocking bug ...
>> * distros.conf should come with testing=buster
>
> /me shrugs, really. also the next really will be "stretch" :)
At least there was a 50% chance to get this right without checking
again :-) I'll probably remember that now.
> distro-info, like it's now done for ubuntu (in piuparts since 0.60, iirc),
> should be used.
patches welcome, I'm too lazy to learn distro-info and would just
s/jessie/stretch/
(would distro-info allow for a timely switch in sid?)
>> * recheck systemd related things in jessie/wheezy2jessie after systemd
>> 215-6 enters testing (dependency swapping according to tech ctte decision)
>
> I think that's what gathered the idea to enable --scripts by default...
Maybe I should try this way of invoking piuparts, too :-)
(without --scripts) Any suggestions which packages to test?
If we turn on some scripts by default, we should provide a
--no-defaultscripts option.
Andreas
More information about the Piuparts-devel
mailing list