Re: [DNG] Conversion script for maintainers
dear Massimo, you are very welcome :^) I'm happy to see here a fellow VUA :^D down to business > If (assuming that) we are going to lose the source of init scripts > upstream, then it's the only way forward. (For those who consider > recognizing the unit files as a valid source a defeat: I may agree > with you, but sometimes a strategic retreat can lead to victory). I agree, but more than a defeat, this is a repairing strategy against an hostile move. Those involved in Debian and SPI should acknowledge they are being hostile to the UNIX community at large. About having "an Interpreter, for the UnitFiles, that then internally do things as SysVInit does": I have privately experimented with this for a while now and there are corner-cases, but it is feasible, if such cases can be taken care of. You adress very well this issue with your reasoning: > My impression is that it is viable building a batch init script > generator, where package maintainers are able to check and validate > the newly generated init scripts *in the maintainer test system*, as > well as take care of any peculiar bug of the translation, or quirky > behaviour of the unit files. This would mean having two things at least: 1. a DSL parser for the conversion of unitfiles to shell scripts say "systemd2sysv". 2. an easy way to test the shell scripts generated, which is also crucial to the task: the quality of the testing environment. 3. optionally, a way to repackage and test semi-automatically an existing deb package undergoing this conversion. I have experience writing DSL parsers and recommend using either: 1. stb_c_lexer by Sean Barrett, part of the STB C lib collection 2. libhammer by Meredith Patterson, part of langsec.org more complex, but way more secure, not sure if this level of security is needed however Assuming of course whoever writes this likes to make it in C, which I'd recommend. I wholeheartedly agree with all your reasoning, quoted below. I don't think that converting automatically at init or at package install is a good idea: we need to keep this process under scrutiny by maintainers, hoping more people will help Devuan, at least on converting scripts for important packages, and make life easier for them. > As it's systemd we are talking about, I wouldn't ever place a bet on > stable and documented behaviour on its part. Otherwise we wouldn't > be here on devuan ML, after all. When new peculiar behaviour is > discovered, we can adapt the initscript generator. This would mean a > huge effort on repacking debian packages, or having blanket-like > packages with init"scripts" for SysV/openrc/any_init that provide > the init support to all/groups of debian packages, possibly synced > with major revisions of devuan. > > On the other hand, a unitfile *interpreter* is a different story, > I'm not sure this is viable as of now, and the risks look greater to > me in this case. IMO there are two scenarios. > > > 1) the interpreter is external to SysVinit/any_init init and is > called after each package update (by means of apt ?). Still, any > bug that creeps through by leveraging unexpected unit file behaviour > will risk of breaking the interpreter *in the devuan user system*, > and this would negatively affect devuan reliability. Imagine the > backfire of a situation where the interpreter fails after a security > update for some obscure change in a unit file, so at service > start/stop or at next reboot the system goes astray. > > 2) the interpreter is run by the init process (bound to it some > way) and used each time a script is accessed. I'd rather not see > this, more complexity of this kind in the init process is bad for > system health. > > I agree the interpreter idea is technically intriguing, but bot > scenarios are a bit too close to reimplementing systemd, IMO. I'd > rather develop something useful to the mantainers now, and keep the > option to turn it into a package for the end user later on. So I'd > first go with 1) the offline translation, 2) get it stable enough > that it can run automatically on any debian package updates, 3) > monitor the amount of bugs and manual corrections needed, then 4) > enable the initscript to be automatically generated and added to > packages in devuan, 5) monitor again for errors 6) consider putting > the interpreter in the final system. > > We can have both solutions along this path but I think the solution > with shorter development time and biggest advantage to maintainers > should be prioritary. many thanks ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On Sat, 30 Nov 2019, Hendrik Boom wrote: > On Fri, Nov 29, 2019 at 07:21:54PM +0100, Massimo Coppola wrote: > > > > > If (assuming that) we are going to lose the source of init scripts > > upstream, then it's the only way forward. (For those who consider > > recognizing the unit files as a valid source a defeat: I may agree > > with you, but sometimes a strategic retreat can lead to victory). > > If we are worried about losing init scripts upstream, I suggest we > maintain a version-controlled collection if initscripts somewhere so > that if one disappears from a package we can restore it. This is what I'm really unsure of, so far. Every time I tried to debate this with someone knowing Debian better than I do, we ended in disagreement. My opinion however is this: maintaining a *unique package* of version controlled init scripts in Devuan is much, much easier than maintaining a sysvinit script in each different package, forking it. I'm not sure about pressing counter-arguments against this. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan cannot exist without the help of Debian
On Wed, 27 Nov 2019, Joril via Dng wrote: > On 26/11/19 22:13, viverna wrote: > > > > I wrote this summer in this list about a possibility of inject init > > > > run scripts (for example runit) in all Devuan packages automatically. > > > > > > This is a great idea. I've been in favor of something similar since > > > 2015. It frees "upstreams" from the responsibility of maintaining init > > > script/configurations for init systems they don't care about or perhaps > > > despise. Daemon start files are written by experts on the init system. > > Sadly it's not just init scripts: for example how would a case like > http://bugs.devuan.org/db/27/276.html > be handled? I guess by hand. do you know about other show-stoppers for the systemd unit conversion plan? BTW, with this mail you just helped me fix this annoying bug on my beowulf day to day install :^) did not knew the fix thanks, ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Please stop this nonsense - Was: Re: Formail for managing digests
dear Bernard,
thanks for your mail, I find it frank and constructive overall
On Thu, 28 Nov 2019, Bernard Rosset via Dng wrote:
> On top of that, add uncertainty on Devuan's future & demotivating
> peremptory statements ("I'm sure Devuan will not survive without
> Debian's help.") and I am close to be utterly certain we are
> colliding with a wall down the road.
noone here will build that wall, but we should be aware is getting
built and I believe that, even if its a shock to see it, its still
better than continue to drive while not seeing it.
this is also about the responsibility we have taken, which isn't
small: many people trust Devuan for its demonstrated stability. we
should never betray who really trust us and is able to see beyond an
april fool's joke gone awol. in case we cannot make it, we shall admit
it IMHO. I have *personally* admitted to see a wall that is hard to
circumvent and I want that people building that wall know well what
they are doing.
Also makes me happy to see a growing amount of thinkering to solve the
situation and avoid an arms race which we'd lose: the discussion on
converting systemd units is a good example of a qualitative solution
at hand. There are well skilled people listening and they may decide
to help Devuan. I would love to be proven wrong on my beliefs and
prefer to be depicted as an idiot here than to see Devuan die. Been
through that anyway.
So, we will not go easy through that good night. But Debian developers
should really know their responsibilities. I believe many of them have
a strong ethical sense about what they are doing.
ciao
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan cannot exist without the help of Debian
On Sat, 23 Nov 2019, Andrew McGlashan via Dng wrote: > I have tried ASCII 2.0 -- but it looks like there is a new 2.1 > version just about to be announced? yes, there is a 2.1 ready and most of it is thanks to the passionate work of volunteers, among the few fsmithred, rrq, golinux, centuriondan and evilham. I believe there wouldn't be this point release without them. Only the VM and ARM images are lagging behind, which is mostly my fault. The place of reference is always files.devuan.org and the release notes are updated https://files.devuan.org/devuan_ascii/Release_notes.txt Devuan's history can be easily traced connecting people and versions, which also shows how much of the sustainability of our project is bound to individual initiative and vision. Devuan is not resilient. If Debian stops providing the forest around our cultivated patch, our plants will die. the VUA will announce the 2.1 point release tomorrow, on Monday. I believe all of us are motivated to continue in our best capacity to support Devuan, but I really do not want to see any of the great people involved burn out because of an incommensurable challenge. what we can also try is to scale Devuan's effort with an enterprise approach, but then we need clear commitment from at least one strong and reliable industrial partner. all this of course IMHO, I'm not speaking for Devuan, but sharing with you my personal opinions on this project ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Devuan cannot exist without the help of Debian
dear readers, I write this email to comment on the current Init System GR vote in Debian, see https://lists.debian.org/debian-vote/2019/11/ I'll be brief and express my personal opinion on the matter. Devuan cannot exist without the help of Debian. When me and Franco Lanza started this project in 2014 it was because of the most painful Init System GR in Debian. Back then, we chose Ian Jackson as the best Debian developer to represent the interest of Debian's users and to defend the true mission of the Debian project as a universal operating system. While supporting Ian's proposal we also promised to the world that, if that wouldn't be the route taken by Debian, we would have not gone gently into that good night. So we did, and Devuan was born. Together with a small group of volunteers we dedicated huge amounts of time and resources to Devuan, putting our skills at the service of a very large community of people in need of Init Freedom; a whole chapter of my doctoral thesis is dedicated to this project https://pearl.plymouth.ac.uk/handle/10026.1/11101 and overall our history is rather well explained here https://devuan.org/os/init-freedom/ and our community well represented by the first Devuan conference we organised in Amsterdam https://www.dyne.org/the-first-devuan-conference/ For many of us Devuan has been a source of pride, joy and professional relief. It brought together some of the best people, developers and system administrators I could ever hope to meet in my life. We also managed to contribute back solutions and software useful to the Debian project. Now please let this success be an account of how important is Init Freedom for the large amount of Debian users out there. Today I write you because there is a reason to be worried that many Debian users will be betrayed once more by its leadership. And today once again I support the vote proposition nr.4 by Ian Jackson and urge the elite who has the privilege to steer the future of Debian to pay good attention to this choice, considering Ian's competent and well informed formulation. At last, please, do not consider Devuan as an alternative solution which will survive any outcome of this vote. Because I'm sure Devuan will not survive without Debian's help. Devuan is much, much smaller than Debian in resources, people and infrastructure, and despite our efforts were useful to both, the Debian project has done very little to help us so far. If Debian drops the support for any other init system but systemd, I believe we won't be able to keep up with the legwork needed to support all other init systems. I say this because we do not have a comparable amount of people and resources to face the huge amount of work Debian will cease to do. Of course quality matters, but not that far. If the resolution nr.4 proposed by Ian Jackson will not pass, Devuan will die. -- Denis "Jaromil" Roio https://Dyne.org think tank Ph.D, CTO & co-foundersoftware to empower communities ✉ Haparandadam 7-A1, 1013AK Amsterdam, The Netherlands 턞 crypto κρυπτο крипто गुप्त् 加密 האנוסים المشفره ⚷ 6113D89C A825C5CE DD02C872 73B35DA5 4ACB7D10 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
