Re: Please drop anacron from task-desktop
On Fri, 8 Mar 2019 at 14:48, Holger Levsen <holger@layer-acht.org> wrote:
>
> On Fri, Mar 08, 2019 at 01:46:59PM +0000, Daniel Reichelt wrote:
> > > Shouldn't that be the other way around? Having .timer but not a cronjob is
> > > a nasty bug, having a cronjob but not .timer is fine (at least unless you
> > > have no cron implementation at all).
> > +1!
>
> /me yawns. init systemd discussions are sooo 2014. Debian has settled for
> a default desktop, a default kernel, a default editor, a default init
> system, a default logo, a default filesystem...
>
default buildds to split-usr, thus supporting either merged-usr or
split-usr installations.
default to source-only uploads, because accepting arbitrary built
binaries is odd.
> And surely we support other, strange and not so strange, choices,
> sometimes more and sometimes less, but yawn.
>
Or asking to support things, that in practice are hard and of
questionable benefit - ie. support cross-combinations of building
packages on merged-usr to be then deployed to split-usr. It's like a
new twist on the ultimate buildd from hell. (the test rebuild that
used as dirty chroots as possible to rebuild debian from way back
when). And specifically, since this has never been done before by
anybody and is not at all required to be a supported buildd chroot
configuration. A clean buildd chroot; should not, and need not, be the
same as a runtime chroot/container/installation. It is convenient when
they are, but it is not the best way to achieve the desired results
(clean universal package builds vs great individual runtime
environment).
Specifically about default init, I find it extremely difficult to
justify continous synchronisation between init.d scripts and systemd
units states, whilst the other init is not in use. Imho, it is odd to
continiously update rc*.d symlinks for init.d scripts on systemd
booted machines for things that have native systemd units. Or vice
versa. Switching init is intrusive enough, and imho we should be
dumping the enable/disable state of the systemd units and
creating/removing rc*.d symlinks on an init switch only. It is madness
to support dual boot with either systemd or sysvinit as init
simultaniously at any given time a given installed system.
I guess it is time for me to start drafting GRs to assert our
position, that default choice should work well and should not be
unduly burdened by the non-default, or arbitrary combination of
non-default choices.
--
Regards,
Dimitri.
Reply to: