KatolaZ <katolaz <at> freaknet.org> writes:

>
> On Mon, Feb 16, 2015 at 11:01:36PM +0000, Luke Leighton wrote:
>
> [cut]
>
> >
> > what you *don't* want to happen is to fall into exactly the same trap
> > of forcing people into all-or-nothing decisions. we've had enough of
> > that, and it would be respectful to them to give them a proper choice,
> > and to show other distros (including debian) that respecting people's
> > right to choose is something that attracts users.
> >
>
> I see your point, but you will agree that it will be almost impossible
> to keep two versions of the same (group of) packages (one with and one
> without systemd support),

no, because not only do i consider it to be reasonably easy to do,
but also because it's exactly what the devuan team is planning to
do and is well on the way to already achieving :)

> and also useless, since the version "with
> systemd" will be altready shipped by Debian....

... that's their problem, and one that is well on the way to being
fixed as the first priority of devuan's milestones.

by providing "altered packages" that mask all and any packages in
debian that include or depend on systemd, the fact that debian
has any mention of systemd becomes completely irrelevant.

that's what the pinning and the package renaming is all about.
isaac showed how it's done, a couple of days ago.

> I am sorry but I don't understand the necessity to be "100%
> compatible" with Debian at all costs.

that's because you misunderstand the point i am endeavouring to
get across. you believe i have said "be 100% compatible at all costs".
i did not.

i said, "if you try to go too far, you will overwhelm the team
with the amount of work that will need to be done".

i *recommended* therefore that you keep the differences to an
absolute minimum. *not* "be 100% compatible at any cost".

is that now clear?

> Again, this will probably be
> almost natural for the first release, since Devuan developers are
> focusing on making the fewest necessary changes, but I am convinced
> that it will soon become unpractical if not impossible, at least if
> alternatives to udev and dbus will be included in Devuan and other
> packages will depend on them.

ah, that's where i have confidence that you, as a team, will be very
very clever, think this through and come up with something that achieves
exactly and precisely that :)

and i think, also, if you do a full and careful audit, you'll find that
there are only a few strategic packages that you need to cut off at
the knees, and beyond that subset of packages the impact will be
zero.

also, i'm going to have a word with the systemd team. i'm going to
advocate to them that they make libsystemd0 be a dynamically-loaded
runtime library, and to provide demonstrations (starting with
pulseaudio) where applications check at *runtime* if libsystemd0 is
available, rather than hard-code the functionality directly in.

if they don't listen, i'll do it myself. argh. :)

l.