On Fri, Jul 17, 2015 at 01:52:56PM -0500, T.J. Duchene wrote:
> KatolaZ:
>
> > > > You guys talk about supporting half a dozen init systems like it
> > > > was similar to providing half a dozen different editors, which
> > > > believe me is not quite the case.

This is true, because supporting an init system requires every package
that provides a daemon to work with that init system's boot scripts.
And you can't really define a single format for boot scripts, because
that's a fundamental part of how an init system works.

Editors, on the other hand, are interchangeable in terms of usage:
all of them work with
$EDITOR $file

<snip hendrik>
> Hi, guys! Just my two cents!
>
>
> Just to be clear, before I say anything else, I am not talking about
> Devuan 1. That's set in stone. As far as the future, I personally
> think that init freedom/flexibility is something that really needs to
> be evaluated, so that Devuan does not fall into the same mono-culture
> trap that Debian has. One of Devuan's key concerns should be the
> avoidance of mono-culture thinking.
>
> I actually read somewhere that Ubuntu is already planning on abandoning
> the Deb format in favor of something new. I wasn't too thrilled with
> the idea at first, but the more I thought about it, the more I am
> convinced that something has to change. Ian Murdoch who
> founded Debian, advocated changing the way things are done (when he
> started Progeny, but because he wasn't the head of Debian he was
> basically ignored). Debian packaging practices NEED to change as needs
> change, and they haven't. Even RedHat has changed their packaging more
> than Debian.
>
> It was packaging that led to Debian's systemd versus S5 fracas
> in the first place. Being a programmer and having packaged software for
> both Debian and RedHat style Linuxes, I see absolutely no reason why it
> is not technically feasible to support multiple init systems. Even if

I'm not sure how "include the init scripts for all init systems in the
core package" is not technically feasible.

> you know how to man-handle APT, there are too many longstanding issues
> in Debian packaging that never get any attention at all, because the
> vast majority of the Debian developers always use Sid. There are no
> delta support. There are no (or very few) alternative package chains.

Delta support was proposed but voted down on the grounds that it only
works nicely for upgrades where you know the baseline.
If that's correct, it would be most problematic for cross-release
upgrades.

I'm not sure what you mean by "alternative package chains".

> There are no really reliable methods of rollback for a bad package.

No automated ways, true.
It's possible to do it manually via snapshots.debian.org.
It should be *possible* to use the package meta-information and dpkg
logs to roll it back automatically, and if you don't clean your package
cache that's also an option.


> One thing that drives me crazy is that you cannot pull updated
> source code to use on Debian Stable from the other Debian branches for
> a local apt-build without ridiculously convoluted configuration
> (if it works at all). It's actually the lack of any real change in the
> packaging that has started me looking at other Linuxes for a
> replacement.

If it's a new package, it works fine:
# add deb-src ... stretch ... to a squeeze box
# apt-get update

# Try with a new package:
apt-get source motif
# it works!

# try with an old package
apt-get source -t=stretch bash
Reading package lists...
Building dependency tree...
Reading state information...
E: Ignore unavailable target release 'stretch' of package 'bash'
E: Unable to find a source package for

This seems like -t is parsed without checking whether it's source or
binary, which is a rather annoying bug.

But it's rather annoying that there's no way to automatically get it
from the VCS.

> Debian packaging has become to rigid and inflexible.

I'm inclined to think these are readily solved by extending the package
format and package managers.

> Thanks! See you all soon =)
> T.J.

Thanks,
Isaac