[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#847681: packaging repository and sid diverging? Various fixes needed.



Hello Raphaël Halimi,

Congrats on completely derailing a thread that for once was about
proper mainenance and solving a bigger problem into becoming
about your pet peeve. Please feel free to stop CCing me if you
don't actually want my feedback.

On Tue, Dec 13, 2016 at 11:01:19PM +0100, Raphaël Halimi wrote:
> Wontfix ? Really ? Are you that much intent on killing sysvinit ?

Unless by "killing sysvinit" you mean "use it as intended", then no.

> 
> Last time I checked, the Policy still required alternative init systems
> to be supported by package maintainers.

I wonder which policy you're reading then. Fwiw, I recently posted
patches to policy to make it sysvinit compatible, but maybe we
should go the other way around and cite the current very outdated
policy as a reason for sysvinit removal instead?

> Since it's so easy to override
> these settings with systemd (I'm not ironical here, I really don't know
> how it's done), what harm would this patch do if it was applied to
> satisfy sysvinit users ?

If you think it's about making it easy to do it in multiple separate
ways, then you don't understand the problem. You want exactly
*one* way to do it that's supported by all, so we can continue
keeping that one way working and avoid incompatible upgrades.
You know Debian cares alot about integration and easy upgrades, right?

> 
> They would have at last the possibility of modifying rpcnfsdopts through
> /etc/default/nfs-kernel-server, and thus reliably disable nfsv4, and
> systemd users could still do the same through whatever facility systemd
> provides and that I'm not aware of.

You already have this option. These files are conffiles. Please read
up on what that means (in policy for example).

Maybe also think a bit about why making incompatible changes to
conffiles and shipping new versions of them in a package is something
you want to avoid as a maintainer, and why a user don't want a
maintainer to do that either.

Regards,
Andreas Henriksson


Reply to: