Stop removing Init- Scripts from packages!

[darkside401]

Hi there,
please Package Maintainers stop removing the init- scripts from newly addad ALARM packages, like Samba or Sabnzbd.

This completely breaks the support for all the Oxnas devices not capeable using systemd.

Even worse, people doing a pacman -Syu on such devices nowadays will be left with only a partial functioning device, because deamons like Samba etc. wont come up.

I switched from Debian to ALARM, because in Arch it should be easily possible to run your device with current software packages, but that is worthless when a simple update command breaks your whole installation and you spend hours searching for old init- scripts to reinstall.

[pepedog]

This is going to pile a lot of work on essentially one man (not me btw)
It won't help with a new install, but copying /etc/ conf.d and rc.conf is a good idea.
Someone could be harvesting them too

[silentcreek]

Hey pepedog,

could you elaborate a bit more what the neccessary and and possibly missing files will be?

E.g. when I updated samba and it didn't work anymore, I followed your advice in this post and created a new file samba in /etc/rc.d/
So, from my basic understanding, I assumed that the scripts in /etc/rc.d/ are the ones one should backup. I think my rc.conf wasn't touched by the update, at least samba was still in the list of daemons to be started (I think, but I'm not sure anymore).

Now, will the files in conf.d also be removed from packages? And in the case of the latest samba update, was something else removed aside from /etc/rc.d/samba that one should have backed up/installed again?

Also, is it safe to say, that one can update packages that are not in the list of daemons in rc.conf? So if my list says e.g. network, netfs, openntpd, sshd, crond, samba, then I should be careful not to update any of these packages withouth being aware of the possible problems?

Do you happen to know from which packages the scripts were already removed?

Sorry, for my questions. As you can see, my insights and understanding of linux are minimal.

Thanks,

Timo

P.S.: I created a topic here with the intention to collect information and scripts about files that one will need after a package upgrade and measures to take. Maybe it doesn't have to be a one man job but more a collective effort?

[darkside401]

$this->bbcode_second_pass_quote('silentcreek', '
')Also, is it safe to say, that one can update packages that are not in the list of daemons in rc.conf? So if my list says e.g. network, netfs, openntpd, sshd, crond, samba, then I should be careful not to update any of these packages withouth being aware of the possible problems?

[chat1410]

It's my understanding that all packages for ALARM have a maintainer that is different from the real programmer or package maintainer for Arch Linux.

If this is infact the case, can ALARM request that maintainers leave initscripts in? As far as making a repository of existing /etc/rc.d: I'd gladly donate my /etc/rc.d but really that's just a bandaid.

[xenoxaos]

$this->bbcode_second_pass_quote('darkside401', 'H')i there,
please Package Maintainers stop removing the init- scripts from newly addad ALARM packages, like Samba or Sabnzbd.

This completely breaks the support for all the Oxnas devices not capeable using systemd.

Even worse, people doing a pacman -Syu on such devices nowadays will be left with only a partial functioning device, because deamons like Samba etc. wont come up.

I switched from Debian to ALARM, because in Arch it should be easily possible to run your device with current software packages, but that is worthless when a simple update command breaks your whole installation and you spend hours searching for old init- scripts to reinstall.

[karog]

$this->bbcode_second_pass_quote('xenoxaos', 'A')ctually, we don't remove anything from a package...95% of our packages are exact copies of pkgbuilds from upstream...Upstream is phasing out support for initscripts...essentially, in order to maintain what it is, we would need to keep a separate repo for just oxnas devices and keep it frozen in one state, no updates. OR manually make init scripts for each package manually...

[xenoxaos]

Because every time we've tried porting to a newer kernel...it's unstable and crashes regularly from cache coherency issues.

[WarheadsSE]

It's a matter of I have done work, but I am limited in what I actually know about the underlying hardware, even with the NDA. PLX is not interested in updating the kernel, and actually have sold the unit that produced the hardware family and wrote the kernel!

My efforts along with others have resulted in kernels that are supportive of systemd, however, they are NOT stable kernels, and have as-yet-untraced faults that cannot be deemed "acceptable". Right now, efforts are underway to get uboot partition & usb support all the way to 2013.01-rc's. We've yet to get USB working fully, and we've got a few issues with the sata read (yay! nasty hack by PLX). The reason this is important is it will remove the need to have the kernel in NAND, which is one of the many things I despise about the way the system support stands as it is now.

We're working on it, but, hey, I have to have bread and water.

[silentcreek]

To all developers here,

just to be clear: I'm not complaining at all about the fact that there is no more recent kernel. In fact, I'm already very happy with what alarm enables me to do and I understand that none of you is paid for the efforts you put into this project. Plus, it's not your fault that PLX doesn't support this platform. So, I' really grateful for the work you guys put into alarm, enabling less advanced users like me to use Arch on their devices.
I was just unpleasently surprised that an upgrade with pacman could have such consequences - without any notifications during the upgrade process - but I see a point that you can't support all possible platforms and setups for all times and you don't want to maintain deprecated files. So, for now, I just like to collect all the neccessary information about how to continue to use alarm on my device while leaving me the option to perform updates with pacman safely. An if that is a collection of init scripts and howtos that will help me and others do so, I'm fine with it.

Timo