On 19 October 2012 12:19, Andrea Scarpino wrote:

On Friday 19 October 2012 12:17:06 Lukas Jirkovsky wrote:

...

Hello, I'd like to maintain some basic support support for consolekit in [community], more specifically the polkit-consolekit, kdebase-workspace-consolekit packages and eventually consolekit package itself as long as possible, if you're not against it.

I'm running kde (networkmanager) without systemd without problems on my laptop with these packages.

Please don't. We'll never drop initscripts this way. Use AUR instead.

-- Andrea Arch Linux Developer

OK

On Friday 19 October 2012 12:28:00 Lukas Jirkovsky wrote:

Actually, what would be the problem of me maintaining initscripts in community too, if that time comes? I don't plan to switch to systemd anytime soon. I don't see any problem dropping the initscripts & consolekit packages to AUR when no one (including me) would be willing to maintain them.

We are already having issues in maintaining two init systems. (e.g. we don't know which one users are using, see FS#32028). https://bugs.archlinux.org/task/32028 -- Andrea Arch Linux Developer

On 19 October 2012 12:46, Allan McRae wrote:

On 19/10/12 20:28, Lukas Jirkovsky wrote:

...

On 19 October 2012 12:19, Andrea Scarpino wrote:

...

Please don't. We'll never drop initscripts this way. Use AUR instead.

-- Andrea Arch Linux Developer

Actually, what would be the problem of me maintaining initscripts in community too, if that time comes? I don't plan to switch to systemd anytime soon. I don't see any problem dropping the initscripts & consolekit packages to AUR when no one (including me) would be willing to maintain them.

So "maintaining" initscript would me actually adjusting/fixing them as needed or just putting a package there?

I'd probably do only the bugfixing – I don't think there's any new functionality needed.

Because there has been repeated calls for actually contributors towards initscripts without any response. And if you are not going to do actual development of initscripts, I will have to object on the basis that the software is unmaintained upstream.

Allan

It's possible that I missed some of this calls for contributors, but I already presented my will to help. I was told that mostly the testing is needed, and, well, initscripts works for me without any problems, so there are no bug reports from the in this regard. But I don't see any problem in diving into bugtracker and trying to fix some of the current issues too. Lukas

[2012-10-19 08:00:36 -0400] Stéphane Gaudreault:

most devs are not going to provide much support on the rc scripts in their packages once the switch to systemd will be completed.

Certainly Lukas intends to create and maintain an initscripts-arch-rc.d package similar to systemd-arch-units. He would surely not expect every packager to duplicate their work for two init systems, when most of us agree to deprecate one and move towards the other. Right Lukas? -- Gaetan

Le 2012-10-19 08:42, Lukas Jirkovsky a écrit :

On 19 October 2012 14:00, Stéphane Gaudreault wrote:

...

The problem is that it will eventually become an unmantainable mess, not because of initscripts itself (Tom, Dave et al did a great job to keep it in a good state), but because most devs are not going to provide much support on the rc scripts in their packages once the switch to systemd will be completed. Also new packages will probably not include any rc scripts in a short future.

Stéphane I know that at some point of time it will become unmaintainable. But I believe it should be possible to support initscripts for next few months without any larger problems. As for the rc scripts – these are low maintenance, so keeping them is not a problem. I'm sure I will have to switch to systemd on all my systems eventually, but I don't give up that easily ;-)

...

Certainly Lukas intends to create and maintain an initscripts-arch-rc.d package similar to systemd-arch-units. He would surely not expect every packager to duplicate their work for two init systems, when most of us agree to deprecate one and move towards the other. Right Lukas? Sure. If the package maintainer decides to drop rc srcipt from the package, I can keep it in such package. As the rc scripts doesn't need to be changed often I think this isn't a big problem, unless some of the applications starts requiring systemd for their services.

Lukas

Ok, if I can give my rc scripts to you, then I am happy :) Stéphane

On 19 October 2012 14:41, Thomas Bächler wrote:

As long as all bug reports for non-logind systems go straight to Lukas (and whoever else maintains this), I don't care. If we don't have those packages in community, they'll be in a third-party repository - and I prefer having them in community in this case.

Well, I can keep these packages in AUR as Andrea suggested in the first post, but given that according to package statistics [0] there are still lots of systems not using systemd I think having them in community is preferable. [0] https://www.archlinux.de/?page=PackageStatistics

On 19 October 2012 21:06, Jan de Groot wrote:

Please don't. Consolekit is not maintained upstream anymore and should get killed with fire. null

I see no problem in maintaining ConsoleKit in [community] as long as it doesn't cause any problems. The main reason why I'd like to keep ConsoleKit in community is because the kdebase-workspace, which requires ConsoleKit on systems using initscripts, takes relatively long time to compile. If some serious issue arise I won't object to moving it to AUR. But if you are against ConsoleKit in [community], I can keep the consolekit-related stuff in AUR, while maintaining initscripts in [community] (although in fact initscripts without consolekit are nearly worthless for me – I depend on KDE's NetworkManager applet). On 20 October 2012 00:16, Dave Reisner wrote:

Package stats is purely aggregate. There is no such thing as tracking of users or machines, so anyone who's reported and uninstalled initscripts since, and then reported again isn't going to have the "desired" effect. Sadly, in its current state, there's very little stats in package stats.

d

Thanks for clarification. Lukas