On Mon, Jan 05, 2015 at 09:15:11PM +0000, t.j.duchene@??? wrote:
>
> >Then I have no idea about default installation (you can probably look at
> >package dependencies to figure it out). But from Debian's current POV, it is
> >probably considered an improvement to add systemd components and more
> >recent versios of ______ that use them, even if PID1 is still sysvinit. After
> >all this is what Ubun7u and Trisquel are doing.
>
>
>
>
>
> Probably. To be clear, I don’t know if that is the case or if they
> simply did something else, like rename a package. Either way, I call
> it “crap.” You can purge it with no error,

No error when you purge it. I presume you can still log in? And you
can still boot?

> but aptitude wants to
> reinstall it the next time the resolver is run.

A later post suggested it may have come in with backports.
Would removing backports from sources.lst keep it from coming back?

> There is no reason to change to this that I can think of. Without
> looking at the code, I’d guess that it is just a bad dependency chain
> introduced in the last update - otherwise I couldn’t guess as to what
> they were thinking.

If it indeed came in with backports, maybe there were users who asked
for it to be backported?

By the way, is there a good way to find out what other packages might
have forced a package to be installed as a dependency (directly or
indirectly)?

-- hendrik

>
> To me at least, this incident is just another example of the QA
> pitfalls of the traditional “Linux distribution” process. They talk
> about stability and maintainability, but the second that that becomes
> fashionably inconvenient, they introduce new things into mix even
> after “the cake has been baked.”
>
> Every spec is only kept for as long as it is convenient for the
> packager to do so, the user’s actual real world needs play second
> fiddle.