How do I keep up with all these dependency updates / QMPlay2?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Well, orbea, perhasps i should've emboldened this in the original post
I did say "The only people I know of who actually need the assumed "latest and greatest" are some software developers. If you are one, I'd suggest using some rolling release like Arch for development, and Slackware for running the things you love and protect."
I wasn't at all implying that Slackware was not "a great development release". I know that it is! .... except for those few ( the some) who require the absolute latest software versions. I've met several and many of them use Arch and claim to have no problems with breakage, but then they've used it for quite some time and have both experience and knowledge to prevent breaks and back out when they mess up, so it hardly classifies as "terrible advice". It's just a matter of knowing the right tool for the job and how to use them properly.
Distribution: Slackware/Salix while testing others
Posts: 1,718
Rep:
Quote:
Originally Posted by enorbet
Well, orbea, perhasps i should've emboldened this in the original post
I did say "The only people I know of who actually need the assumed "latest and greatest" are some software developers. If you are one, I'd suggest using some rolling release like Arch for development, and Slackware for running the things you love and protect."
I wasn't at all implying that Slackware was not "a great development release". I know that it is! .... except for those few ( the some) who require the absolute latest software versions. I've met several and many of them use Arch and claim to have no problems with breakage, but then they've used it for quite some time and have both experience and knowledge to prevent breaks and back out when they mess up, so it hardly classifies as "terrible advice". It's just a matter of knowing the right tool for the job and how to use them properly.
Current perhaps for those (few)....Personally, I would pick openSUSE tumbleweed over Arch if I was forced to choose between those two for those few.
That is usually because the SlackBuilds are not executable when you get them. You need to:
Code:
chmod +x ./slackrepo.SlackBuild
making sure that you are working in that directory via your terminal.
And if you downloaded the master branch from idlemoor's GitHub, you'll need to extract the zip file, put the whole lot in a directory (or rename) named slackrepo-3.0, compress it as a .tar.gz, then copy the SlackBuild, info, Readme, etc in the same directory as the archive you just made and then run the SlackBuild.
Thank you. Now I just have to learn how to use it.
It is a very powerful program, so it may take a bit to get fully spun up on it, but depending on your usage, it may be well worth the effort (it certainly was for me). I started a topic on it to document my setup process and to ask questions. I got much bigger than I anticipated. There's a lot of great info in there (and many of the suggestions we've made in that thread are now in the latest source code from github). Check it out when you get a chance.
Well, orbea, perhasps i should've emboldened this in the original post
I did say "The only people I know of who actually need the assumed "latest and greatest" are some software developers. If you are one, I'd suggest using some rolling release like Arch for development, and Slackware for running the things you love and protect."
I wasn't at all implying that Slackware was not "a great development release". I know that it is! .... except for those few ( the some) who require the absolute latest software versions. I've met several and many of them use Arch and claim to have no problems with breakage, but then they've used it for quite some time and have both experience and knowledge to prevent breaks and back out when they mess up, so it hardly classifies as "terrible advice". It's just a matter of knowing the right tool for the job and how to use them properly.
Have you actually ever used arch? Pat often updates core pieces of software like llvm long before arch does and when that update breaks some program developed by someone using arch I've seen them refuse to look into it until arch followed suite and updated the program as well (Several weeks later...).
My personal experience using arch was that it turned into a full time job undoing everything other people did wrong...personally I have better uses of my time than blindly typing 'pacman -Syu' and hoping nothing broke. And if you spend an extra week not doing that your system will become out of date and fail to update smoothly unless you spend more time coercing it into doing so. Arch is bleeding edge in the sense that it's profusely bleeding from all sides while their army of maintainers shove every and any band aid on it hoping that it can only be better...
Have you actually ever used arch? Pat often updates core pieces of software like llvm long before arch does and when that update breaks some program developed by someone using arch I've seen them refuse to look into it until arch followed suite and updated the program as well (Several weeks later...).
My personal experience using arch was that it turned into a full time job undoing everything other people did wrong...personally I have better uses of my time than blindly typing 'pacman -Syu' and hoping nothing broke. And if you spend an extra week not doing that your system will become out of date and fail to update smoothly unless you spend more time coercing it into doing so. Arch is bleeding edge in the sense that it's profusely bleeding from all sides while their army of maintainers shove every and any band aid on it hoping that it can only be better...
Yes, I have used arch and also a derivative, Manjaro and frankly I don't like either of them. I am not a dev employed by anyone who requires up-to-the-minute versions and I consider all rolling releases risky at best. That said I can't ignore the fact that I have met several serious devs who think it's the best thing since sliced bread. I figure one of two things must be true. Either with time and experience the risks become manageable and the rewards they apparently need make that a good cost/benefit ratio, or they have just never experienced a distro as solid and relatively maintenance free as Slackware. It may be worthy of note that at least four of these devs habituated a forum I subscribe to and over time I learned they were solid coders and worked for fairly large IT departments of large corporations where downtime is money lost.
I sarcastically recommended arch because if you are that sort and think you really do need constant updating then who am I to tell anyone "No!" even though I consider it largely counter-productive. I thought my posts made it obvious that I consider hardware to be the only truly compelling reason to update software. My apologies if that wasn't clear.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.