I thought the very definition of a RUNTIME dependency was that any package with a runtime dependency on another would not have to be rebuilt if the runtime dependency changed but the package itself did not. Not to mention that any target system wouldn't need the runtime dependency itself for the package to function. (Mainly tools used to generate documentation from source would fall into this category.)

Apparently there isn't consensus about what is a buildtime dependency and what is a runtime dependency.

I was interpreting "buildtime dependency" as something needed at buildtime but not at runtime -- tools used to generate documentation from source would be an example of that.

And "runtime dependency" would be something that is not referenced in the build and is needed only at runtime, maybe by shelling out to a command line interface or by the kind of lazy binding you get in interpreted languages.

I am *very* reluctant to say that lazy bound dependencies in interpreted languages like Python don't need rebuilds. APIs change all the time, with or without strongly versioned shared libraries. If we're lucky, a rebuild will re-validate any version constraints in (for example) requirements.txt, and fail the build.

I'd just like to thank you for creating this program and for keeping it maintained!

Question: does slackrepo resolves dependencies? I just compiled youtube-viewer, which is standalone youtube viewer, but there is some number of dependencies, I was using sbopkg, but for sbokpg it is up to me to properly set up build queue.

Hi,

It resolves everything that is in REQUIRES in .info.

--
Best regards,
Andrzej Telszewski

Nice, but it would be good to have something for optional dependencies. Say the viewer I mentioned has opional dependency to be build with gtk, I don't remember is there a field "OPTIONAL" in .nfo? I could verify but SB site is down now.

Hi,

No, there's no OPTIONAL in .info.
You can teach slackrepo what are your optional dependencies and it will pick them from then on.

--
Best regards,
Andrzej Telszewski

life is difficult sometimes, something is wrong with me?

I will throw this out there... slackrepo is a different beast than sbopkg. slackrepo expects (but it isn't required) that the host system be clean, meaning no 3rd-party packages are installed (minus slackrepo, of course). This ensures that all your packages are clean and only link against the dependencies you intend for them to link to... and the big benefit behind that is anyone running Slackware should be able to install those packages and dependencies and have it work fine. Otherwise, if you build a program on your computer, you may not intend for it to pick up some dependency that is already on your computer, so when you try and install it on another computer, it fails to run.

Since slackrepo likes to be on a clean installation, it means you'd probably need a separate machine or VM for it. The great thing about it is it can output all the packages into a repo similar to Alien Bob's, allowing a number of 3rd-party package managers to install from it. The downside is this is quite the project if you're only going to be installing packages on one machine. There's still benefits, but it does take a bit more work to handle.

With that in mind, while I love slackrepo, I do realize it is a bit of a shotgun approach when someone might need a scalpel (depending on your perspective... I think it is a scalpel for my needs since I can be extremely precise). If you feel that way, sbopkg still has some secrets and might still be able to fit your needs. It includes a companion script called sqg that will generate queue files for you based on the program's REQUIRES line in the .info (you just run sqg -p $PRGNAM and it will generate the required queue file). If you need additional optional dependencies, you can use the editor built into sbopkg to edit that REQUIRES line (I did that with ffmpeg). Once a queue file is generated, you can simply run sbopkg -i $PRGNAM (replacing $PRGNAM with the name of the program you're wanting to build). sbopkg will ask if you just want to build the program or the queue file, which you respond q for the queue file. From there, it will chug along and build all the dependencies listed in the order they need to be for the final program to be built and installed.

All that being said, I still love slackrepo and it can still be a powerful tool even if you are only using it to build packages for one computer. If you're interested in checking it out, you can use my mirror of his slackrepo-0.2.0rc1 package or you can get the latest work from his github (which has added a lot of additional features and is nearing a new release).

1 members found this post helpful.

this link is dead, but I downloaded from your own mirror. Thanks. For sure I'll give try.

s/idelmoor/idlemoor/

1 members found this post helpful.

Fixed... thanks. That's what I get for typing it rather than copy/paste.

Ah. In that case, I'd say the confusion would be on my side.

Well... if you have some confusion, I'd be inclined to say that the concept needs more work. [1]

For avoidance of doubt, I am not saying *never*, but I am saying that maybe there is a more intuitive concept hiding in there somewhere that we can implement instead. If the problem is too many rebuilds, maybe the solution is less rebuilds.

[1] or its documentation, but in my opinion "This index contains 579 entries, referring to 216 individual manual pages" just says "we don't understand il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher".

Hi,

Language is a bitch ;-)

What I meant by RUNTIME was optional application, that might be or might not be present while the main application was running. In addition, update of RUNTIME wouldn't cause the dependant application to be rebuilt.

This came out from (if I recall correctly) krusader, which might optionally use multiple different applications. And, updating any of those applications, should not cause krusader rebuild, because they are binaries called by krusader.

We could think about something like RUNTIME_REQ, RUNTIME_OPT, but I think this all is becoming messy to say the least.

So, I think the best option is to allow the user to decide, by marking the package as not needing the rebuild.
Say, you run slackrepo with --preview switch to see what is going to happen and then you can decide which packages are going to be rebuilt and which not.

BUILDTIME= is a very welcome addition and I think it'll serve it's purpose.
For example, when you don't want to populate the tools used during build to the target machines.

(I haven't yet updated to the latest git to test, but I will soon :-)).

--
Best regards,
Andrzej Telszewski