I've already upgraded Deluge once from the current version on Slackbuilds. Now I am getting a Deluge is updated again message.
deluge (1.3.13) <-- slackbuilds.
Deluge is up to 1.3.15 .. I know it is just a little bump, but when does it start becoming problem with matching dependencies, and how would I know, before or after it is too late?

In other words is it a good idea to just keep updating Deluge (or like pkg) that give no indication if they need updated dependencies along with it?

As with most if not all other Linux/GNU distros this end of it is just automatically taken care of, if dependencies need updating along with it, then the package maintainer app thingy (apt-get etc...) automatically knows then they just are.

How do I go about finding out without a lot of chasing down everything to find out in Slackwhere?

It is not always an easy process to know. However, if the package you're wanting to upgrade does not have any programs that rely on it (so, if deluge isn't a dependency for any other program), then you can always upgrade.

With various dependencies, it is a mixed bag. Technically, you should only need to rebuild all downline packages if the dependency's ABI changed, but that doesn't always work in practice. Many developers will try and keep similar versions when the ABI is the same and more drastic version changes when it changes (so, 0.31.1 -> 0.31.2 is likely ok, but 0.31.2 -> 0.39.4 might have changed). However, there's really no way to tell without checking the dependency's changelog (if they even list the change).

This is why I like slackrepo. It will automatically rebuild downline packages when a dependency has changed. It simplifies this process immensely.

Might just go and check that one out. Deluge is good enough reason to give it a try out with.

I am currently using the sbotools -> sboinstall to pull off of slackbuilds and build and install pkgs. Then I run into this situation with blender too and a few others as well ...

Thanks ..

Deluge itself shouldn't be an issue, since nothing relies on it. If there's an update for deluge, you can install it without worrying about breaking anything else. However, since deluge relies on, for example, libtorrent-rasterbar, and that relies on GeoIP, it is possible that a change in GeoIP would require libtorrent-rasterbar and deluge to be rebuilt (or possibly just libtorrent-rasterbar, depending on how things are linked).

The same goes for Blender. Unless you're running mitsuba-blender or yafaray-blender, an update to blender would not require anything else to be rebuilt. But one of blender's dependencies being updated could cause a number of different programs to be updated. Like if x264 was updated, it would require ffmpeg to be rebuilt. If ffmpeg is rebuilt, it might require a large number of downline programs to be rebuilt (like blender, mkvtoolnix, kodi, or gst-ffmpeg -- and rebuilding gst-ffmpeg may require other downline apps to be rebuilt too).

I long avoided doing updates because of how bad this situation can be. When you have 100s of packages installed from SBo, and an update is put out, it can be extremely difficult to figure out whether something needs to be rebuilt or not, so I would usually ignore it, unless I started getting errors while trying to run programs. Slackrepo has solved this for me, but the recommended setup is to have it on a standalone, clean install of Slackware (I use a VM, since I don't have a machine I can dedicate to it). So, slackrepo can be much more difficult to get started with, but it handles updates of dependencies beautifully.

Yeah I read up a bit on that slackrepo. It does not seem worth installing and do whatever I need to do to get it to install deluge. Already updated it.

as far as blender too I can do the ole' download the pre-compiled one and create a soft link to it in /usr/bin as I have done before I decided to use slackbuild script to keep it up to date.

I do not have that much installed on here to worry about using slackrepo on second look. I think I'll just keep using sbotools as it looks like it is sufficing.

Thanks again.

marking solved.

There was another similar thread recently, which would also be worth reading.

http://www.linuxquestions.org/questi...ys-4175603071/

It sounds like you installed Deluge from SBo and updated it to a version not in SBo. If the software upgrades itself, that is usually very safe. If you are compiling it from source without the SBo slackbuild, a well written program will check for dependencies and if you don't have the correct ones installed it will generate an error.

If you are upgrading just because a new version is available and not because you need whatever changes were made, I recommend you don't upgrade and wait until the SBo version is upgraded. It is the SBo package maintainer's job to make sure you have all the correct dependencies installed.

Deluge is a bittorrent client and it is unlikely anything else depends on it.

Yep that is what I do when I do not see the updated version in Slackbuilds. Like Lazarus and fpc for example.
I just use a slackbuild script for deluge when change the ver number inside of it then run it, building an SBo in /tmp then update it from that one.


yeah about that wait until slackbuilds SBo updates thing. Now lets take a look into that. How many or does everyone that submitted a pkg to slackbuild still actively maintain it? I don't think so.
Delue has already gone through two updates, but it is still not reflected on the slackbuilds. not even that one before this one, that has been there update for at least a mouth now.

this is actually the most I've seen deluge update, as it is x.x.13 on slackbuilds, and now up to x.x.15 on their sight. Because I updated it in what seems like just a few months ago. now it is updated again. to my surprise.

nevertheless, I do not expect them that submitted a pkg to keep up with it. most all of them anyways.

I even had an experience from one of them when I emailed about theirs, and all they wanted to do was pawn it off on me to maintain. instead of honoring their commitment with a quick change in links to get the version updated. which I bet only requires an email to them on slackbuilds and they are the ones that have to do most of if not more work to update the sight then the one submitting it.

The one I submitted to have on Slackware I do not have to worry about updates. Because their will never be anymore updates to it.
Because I forked it then added my own major improvements on it to get it to do what I wanted it to do. Then kept it on Sourceforge until just recently I light bulb went on and I submitted it to slackbuilds. (that was just a shameless plug for my pkg mhsetroot on Slackbuilds, get it today - its free )

but waiting for someone else to update the link that does what I just did, downloaded the updated tar ball and changed the version number in the script so it will now work with the new version. I see no reason to have to wait for someone else to do what I just did for me.

It was just a matter of the dependencies. what if the main package gets to a point that even the dependencies need to now be updates along with it question, I basically asked.

if I get into trouble with doing it this way. it is an easy fix, just remove it then install the older version. fixed done.

Well, speaking as one who has 32 packages I maintain on SBo, I flat out don't keep up with them. I have a life and other things that occupy my time. There's one package, sickrage, that usually has at least an update every day. I can't keep up with that. I'll usually update it when I have a large number of other updates I submit.

The other thing to think about, is anytime there's a new package, it brings the possibility of new bugs. Many maintainers choose to keep a single version and won't update it unless there's a bug that needs to be fixed or worthwhile features added (and they deem those are worthy for the possible instability that might be included).

And some maintainers only added something because they needed it. They may not have any intention on updating it beyond what they had it at. Or maybe they don't even use the program anymore, so they were looking for someone to take over (like someone who emailed them about it stating it was outdated -- that person is involved enough to know there's a newer version).

This is certainly a benefit of the way SlackBuilds, and many builders, are set up. You're able to easily override the version in there to be able to build newer versions (assuming additional aspects of the SlackBuild don't need to be adjusted).

Ok, I didn't understand what you were asking earlier. This is always a potential problem when updating packages. If there's a drastic change in your program that requires a newer version of a dependency, many times they will state it in a changelog. But this may not always happen and you'll notice issues when compiling or trying to execute that program.

I agree with you about the updates. I keep my system updated with all the software I use. I get tired of people yelling, if you want bleeding-edge find another distro. That sh!+ is annoying. Just cause some like using outdated software, does that mean we all should? Apparently the updates rectify issues we didn't know existed. If every app was soooo stable and bug-free, there wouldn't be a need to update. Even when they only update translation files, its beneficial to those who need it.

No you basically answered my question about this. because doing it the manual way using the slackbuild scripts. If they are not updated on the slackbuilds.org then one or I'd have to hunt down every dependencies and check it to see if that too needed to be updated.

then just apply the same method. just as if one is doing it without any of the "tools" that are out there now that automatically pull everything needed and do all of that work for you.

download the slackbuild,script - the tars needed. untar. put the source.tar into the slackbuild dir then open a terminal to that dir and run the script. go to the next one and repeat until all of the dependencies are installed in order needed, then the main package.

doing it that way when ever the source is updated but not on slackbuilds.org it only requires a mod to the script to get it to work. I was just wondering what is the easiest way to find out if a dependency or dependencies maybe needed to be updated too.

to save time in having to go to Slackbuilds to get every script for each dependency and mod it then do what ya got a do to get it complied and installed. only to find out it did not need to be done, any of it, looking at each version checking against every dependency in slackbuilds.org and the original source sight even.


I was just looking for a fast way to find out if any of that needed to be done. with out having to type so much in here as well ..

that take over that persons submission was just him not wanting to have to deal with it anymore as he even stated he no longer even uses it. etc.. He wanted me to take it from him only because I emailed him about it. as I was just in my "lets check this out and see what it does mode" and noticed it was in need of maintenance. not that this is an issue really. everyone has their reasons for doing or not doing something.

nevertheless - I'm back on track --

Unfortunately, given the sizes of the SlackBuilds.org maintainer base and the repository, there will always be some that are not actively maintained. That's why, if you use something and the maintainer can't support it anymore, it would be helpful to step in and take over maintainership if you can. Think of it as paying it forward. After all, it's a community volunteer effort, and everyone's time is limited.

On the other hand, as bassmadrigal stated, sometimes there's a good reason that a SlackBuild hasn't been updated to the latest version.

lets not turn this post into a guilt trip. thank you.

I'm actively maintaining mine on there already

I didn't mean to make you feel guilty. More appreciative, yes, but not guilty.

You can't scratch just one more itch?