30 replies to this topic

[A.A.]

That is not the problem of the 106 packages.

 

There are two reasons for that: the feed build used to build the image again due to a dependency, and some TUNE_ARCH packages had dependencies on MACHINE_ARCH packages, causing them to be build multiple timers per TUNE_ARCH, which in turn caused the PR of the package in the image to be lower than the package in the feed. So opkg sees it as new, while they are binary the same.

 

The issue with incomplete updates is a massive shortcoming in opkg. If you do a simple "opkg upgrade" (which is what enigma does behind the scenes as well), it runs the pre- and post scripts of the packages out of sync. Which is especially a disaster if busybox is amongst the machines to update, as when it is removed for update, all linux commands are removed too (as they symlink into busybox), and after that, all scripts fail.

 

It would be great if we could switch to rpm (and systemd) for OpenPLi 9 or 10, so are don't have these issues anymore.

 

Honestly in this case the issue are the feeds and not opkg itself.

Remember the other package managers are much more heavy in term of size.

 

About systemd, well, people up in the linux chain decided it is the future, nevertheless sysvinit will remain for long in OE.

Cheers

A.A.

[WanWizard]

No, the problem described with opkg is the sequence in which the scripts are executed.

 

Say you have two packages, A and B, in the update.

 

What should happen is:

A - prerm
rm A
A - postrm
A - preinst
install A
A - postinst
B - prerm
rm B
B - postrm
B - preinst
install B
B - postinst

but what does happen is

A - prerm
rm A
A - postrm
B - prerm
rm B
B - postrm
A - preinst
install A
A - postinst
B - preinst
install B
B - postinst

which means that if B was dependent on A, the remove and/or install of B will fail.

 

This is most clearly with an update of busybox: the prerm will remove all symlinked shell commands before removing the busybox binary, after which a lot of scripts fail due to those commands no longer being there.
 

[A.A.]

opkg is still maintained in OE, we should just open a bug.

 

There was a recent post last month:

https://lists.openem...83779506#153625

[WanWizard]

I'll try to constuct a properly documented case when I get back from holiday.

[betacentauri]

„Maintained“. I have an open opkg ticket since almost 2 years. Well, maybe too unimportant as it’s not a bug. But shouldn’t be too difficult to fix…

[Erik Slagter]

 

That is not the problem of the 106 packages.

 

There are two reasons for that: the feed build used to build the image again due to a dependency, and some TUNE_ARCH packages had dependencies on MACHINE_ARCH packages, causing them to be build multiple timers per TUNE_ARCH, which in turn caused the PR of the package in the image to be lower than the package in the feed. So opkg sees it as new, while they are binary the same.

 

The issue with incomplete updates is a massive shortcoming in opkg. If you do a simple "opkg upgrade" (which is what enigma does behind the scenes as well), it runs the pre- and post scripts of the packages out of sync. Which is especially a disaster if busybox is amongst the machines to update, as when it is removed for update, all linux commands are removed too (as they symlink into busybox), and after that, all scripts fail.

 

It would be great if we could switch to rpm (and systemd) for OpenPLi 9 or 10, so are don't have these issues anymore.

 

Honestly in this case the issue are the feeds and not opkg itself.

Remember the other package managers are much more heavy in term of size.

 

About systemd, well, people up in the linux chain decided it is the future, nevertheless sysvinit will remain for long in OE.

 

My $0.02, it's a diabolic choice. Either we stay at sysvinit which is inherently broken and cannot fulfill even simpelest service control, and we will be able to keep serving MIPS receivers, which often (but not always) are restricted on RAM and flash. Or we make the move to systemd, make full use of the capabilities of modern ARM based SoC's and RAM/flash and loose the MIPS receivers.

 

Same goes for RPM. RPM is really not "heavy", considering I was running it a my 80286 at 16 Mhz with < 1 Mbytes memory one day. All our SoC's are really well enough endowed to run RPM, no problem. I think keep using opkg is unnecessary, outdated and severely limiting.

[Erik Slagter]

„Maintained“. I have an open opkg ticket since almost 2 years. Well, maybe too unimportant as it’s not a bug. But shouldn’t be too difficult to fix…

 

Agree. It looks like "nobody" uses opkg anymore. Which can be explained, imho, by the fact that it's inferior to rpm/deb and really no longer required.

[Pr2]

At some stage I think it is time to remove the plug. I really admire OpenPLi that spend lots of effort to build image for old boxes with low RAM. And then finally people complaints that they cannot use or install some plugins, load EPG, etc.
So why not announced that 8.1 will be the last image for MIPS boxes.
You continue to support out of sales boxes since years, that's nice but it is IT world so obsolescence cames much faster, and people will need to know that it is time to take a backup of there box to be able to reinstall them easily without any online feed.

[Erik Slagter]

This is something we have been discussing for several years now and it remains a difficult question.

[WanWizard]

I think the answer is simple: we build as long as

1. it is technically possible to do so (without too much effort)
2. it produces a bootable image
3. it produces a useful image

For the boxes with 128MB flash, at the moment point 3 is already questionable, but there is still space for a softcam, a channel list, and like an epg plugin (after flash about 10MB flash free).

 

I doubt that this will remain the case once we get to OpenPLi 9, but we won't know until we have a buildable hardknott image.

 

With the new server farm we now have the option to split a build run, so we could decide to remove those boxes from the nightly build (as nobody uses them for development or testing), but build them only on demand (for testing towards a release for example).

[Erik Slagter]

I suspect that if we'd switch to systemd, a lot of older receivers would be impossible to build. RPM maybe too, but less likely.

 

For systemd we need the coorporation of the manufacturers because systemd relies on certain kernel features to be available. Still I think it's the one direction we should go. MiLo already has been testing with it on some receivers and apparently he got it working. I have too litle OE knowledge to lead the transition. I can help with the translation of init scripts to systemd config "unit" files though.