Scribe Entware coreutils-uname breaks scribe installer

[elorimer]

@cmkelley I see Netflix made your tagline into a movie!

 

[HTMLSpinnr]

This is by design. The OS default path has /opt entries at the end. When you install Entware, the Entware terminal session* profile (/opt/etc/profile) inserts /opt entries at the beginning of the path.

I assume the reasoning is that if you've deliberately installed an alternate package (e.g. find) you're doing it for a reason and you want it the take precedence. Of course it's the responsibility of the user to be aware of any incompatibilities and adjust their setup accordingly.


* This profile isn't applied to non-interactive tasks.

Of course, when installing add-ons via amtm, it's done interactively, thus that profile is in use and horked the process. Up until this point, I was blissfully ignorant of the idea that the uname binary would have any of those values statically compiled in during build and just presumed that it was making system calls based on what was available in /proc/sys/kernel/*. Lesson learned!

I've removed the add-in uname as I can't recall why I felt I needed it. I do know that some busybox alternatives don't behave as expected when one is used to a full GNU coreutils suite. That said, I appreciate the effort to make the minor changes to any scripts moving forward to be explicit if the output matters.

 

[elorimer]

I wonder if there might be another aspect to this. I've been confused before when I had an unknown entware/firmware conflict. Would it be worthwhile to have a list of entware packages that should be flagged as "hold" so they don't get installed. I don't see there is a point to having uname, for example, or nano, installed through entware.

 

[cmkelley]

I wonder if there might be another aspect to this. I've been confused before when I had an unknown entware/firmware conflict. Would it be worthwhile to have a list of entware packages that should be flagged as "hold" so they don't get installed. I don't see there is a point to having uname, for example, or nano, installed through entware.

Sorry to post on such an old thread ...

Who would get to decide what to prevent from being installed? I purposely install and use the entware less over the firmware version, and someone may want to use the extra features of say gnu grep over the busybox implementation. Maybe the firmware nano is lacking some feature someone is used to having (don't ask me what it might be, I use vi/vim)? The fact that I can't think of a use for the entware uname doesn't mean someone else wouldn't have a use for it.

I'm struggling now with deciding what to hardcode and what not to. printf? less? probably not. sed? chmod? cp? Probably.

 

[elorimer]

I didn't mean some arbiter deciding for you. I meant a list of packages, maybe in the wiki, that were known to have non-obvious interactions, so you could decide to hold them or not. For example, I have put syslog-ng in the hold category because automatically upgrading entware sometimes borks my install of syslog-ng.

 

[SomeWhereOverTheRainBow]

I didn't mean some arbiter deciding for you. I meant a list of packages, maybe in the wiki, that were known to have non-obvious interactions, so you could decide to hold them or not. For example, I have put syslog-ng in the hold category because automatically upgrading entware sometimes borks my install of syslog-ng.

Personally I would put syslog-ng on hold as well. While @cmkelley has done great with the development of scribe, he does not necessarily have the availability or team of developers to keep up with all the rollout entware updates.

Putting syslog-ng on hold comes with a caveat, it does not place dependencies on hold. If entware roles out an upgrade that breaks or changes syslog-ng dependencies, then your syslog-ng which is on hold might wind up breaking anyways.