HOWTO: Initial Setup of slackrepo (plus some questions)
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.
@atelszewski, it looks like the krusader source isn't available anymore. Have you changed your server around or is something broke? Unfortunately, I deleted my previously downloaded source during the qt5 build fiasco thinking it might've been spaced related (it wasn't).
My server is down and will be for some more days.
If you don't find another mirror, let me know how can I pass you the tarball.
I tried to find it, but came up short. How big is the file? I created a quick form on my server to allow uploads (sorry, it's pretty basic... once you click the upload button, nothing will happen until it completes the upload, then it will move to another page). It currently has a limit of 8MB, but I think that should be enough for the source.
I think this would be the ideal situation to add a IGNORE=yes|no option within the hintfile. This would tell slackpkg to ignore any changes to that slackbuild and use the previously compiled version. This could be useful for both developers and end-users, developers for the reasons you state... any minor change would invoke at least rebuilding that, if not a whole chain of other programs, possibly for a simple change of the README. End-users could use it to sit at a specific version if a newer one adds incompatibilities or for something like qt5. That takes forever and a day to compile on some systems (if it compiles at all), and it would be nice to allow your repo to sit at a specific version... then if you deem an upgrade is worth it, you can remove the IGNORE (or change it to no).
That might be one of the options.
But still, I would prefer to be:
1) given all the reasons for a rebuild,
2) asked if I want to rebuild or mark the package as rebuilt without actually rebuilding.
Quote:
Originally Posted by bassmadrigal
I think for developers it would also be extremely handy to have a /etc/slackrepo/$repo/slackbuilds/ folder that can either override files in the regular repo (kinda like your own hintfiles can override the pre-provided ones -- this could allow you to easily change SlackBuilds if you need to tailor them to your system) or you can add your own SlackBuilds so you can test them with the various packages before submission to SBo. If there's an update for one of those programs pushed to SBo, you could simply tell the user and ask which version they want to use (if you really wanted, you could provide a diff like slackpkg does with .new files...
Isn't this better handled by git itself?
I have my local branch based on the upstream one.
Whenever there is a public update, I rebase my local branch on it.
Then I do the diff between the local and upstream branches and I immediately see if there are changes requiring my intervention.
I have my local branch based on the upstream one.
Whenever there is a public update, I rebase my local branch on it.
Then I do the diff between the local and upstream branches and I immediately see if there are changes requiring my intervention.
For people who are familiar with git, probably, but I have no idea how to rebase anything (although, I imagine it wouldn't take much to learn). Up until earlier this year, I had no clue how to use git beyond cloning a repo so I could build from the latest source. Luckily, David took some time to help me learn the basics (branching, commits, and creating patches), but I'm still not that comfortable with it and I still have to google a lot of the commands (although, I have those basics I mentioned earlier down).
Currently, this program is still very usable for someone who has absolutely no experience with git (minus editing SlackBuilds or adding your own), so it would be nice to have the ability to override SlackBuilds or add your own without needing to learn git. It just seems like a steep learning curve just to be able to edit some files or add your own.
Any thoughts on why slackrepo is downloading a source file that's a different name than what's in the .info file? I just got my transgui SlackBuild added to SBo and then went to build it using slackrepo. Unfortunately, when it downloads the source, instead of downloading transgui-5.5.0.tar.gz like is specified in the DOWNLOAD url, it downloads transmisson-remote-gui-5.5.0.tar.gz (which is the name of the github repo).
If I use wget or the browser on the $DOWNLOAD link, it downloads it with the expected name, but slackrepo doesn't. It looks like if content-disposition is used, it renames the download, but bare wget doesn't and leaves it as expected. Is this a new github thing, or did I just misunderstand how it works (since I never use content-disposition)? Or do I need to rework my SlackBuild to deal with this?
(NOTE: The repo being dirty should be unrelated as it is only for the qt5-repack package I have under the libaries/ section)
Yeah, I ended up figuring that out. I'll just have to rework two of my scripts to make sure the downloads always match what content-disposition headers show (one I tried to shorten the name, the other I tried to change the version to an SBo compatible one... I'll just have to use SRCNAM for the first and SRCVER for the second).
I think it was just my misunderstanding on how github managed their downloads. I thought I could rename them to whatever, regardless of the content-disposition, by changing the filename after the release version. I didn't realize that content disposition will override the filename.
slackrepo runs into this issue because David specified --content-disposition in the wget command (which was a good idea). sbopkg does not do this, so when Willy tested the package using sbopkg, it built fine.
Mm, sorry about that. You have exactly the right interpretation of the problem.
The only reason ever why I used --content-disposition was to be deliberately evil. It's intended to find download problems that people will experience when clicking the links on the SBo website and building manually. Unfortunately, it's a bloody awful design decision for actually building packages...
When I re-do the whole download thing to use an sbosrcarch style md5sum tree, it'll be able to downgrade this error to a warning and do the build.
Ok, I'm at it again with another patch for slackrepo. This adds the ability to remove dependencies from the REQUIRES line by specifying a DELREQUIRES line in your hint file for that program (DELREQUIRES was suggested earlier in the thread by atelszewski). It should only apply to the package for the hintfile, not any parent or children in the dependency tree.
This was my first major foray into arrays, so hopefully it is problem free. Let me know if you have any issues.
To apply the patch, save the it and run the following. This is based on his git master, which I think is slightly ahead of the package. If it doesn't apply, let me know and I'll try to rework it for the RC1 release.
Code:
cd /usr/libexec/slackrepo/functions.d/
patch -p3 < /location/to/delrequires.patch
Here's the patch:
Code:
From adf13c0cb6d59ce37aa9a587e22618b1fea005c6 Mon Sep 17 00:00:00 2001
From: Jeremy Hansen <jebrhansen+SBo@gmail.com>
Date: Wed, 29 Mar 2017 19:19:17 -0400
Subject: [PATCH] Add DELREQUIRES support to remove dependencies.
---
libexec/functions.d/parsefunctions.sh | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libexec/functions.d/parsefunctions.sh b/libexec/functions.d/parsefunctions.sh
index fc7cd18..226919e 100755
--- a/libexec/functions.d/parsefunctions.sh
+++ b/libexec/functions.d/parsefunctions.sh
@@ -451,7 +451,7 @@ function parse_info_and_hints
if [ -n "${HINTFILE[$itemid]}" ] && [ -s "${HINTFILE[$itemid]}" ]; then
local SKIP \
VERSION ADDREQUIRES OPTIONS GROUPADD USERADD CONFLICTS INSTALL NUMJOBS ANSWER CLEANUP \
- PRAGMA SPECIAL ARCH DOWNLOAD MD5SUM SHA256SUM
+ PRAGMA SPECIAL ARCH DOWNLOAD MD5SUM SHA256SUM DELREQUIRES
. "${HINTFILE[$itemid]}"
# Process the hint file's variables individually (looping for each variable would need
@@ -581,7 +581,8 @@ function parse_info_and_hints
${DOWNLOAD+"DOWNLOAD=\"$DOWNLOAD\""} \
${MD5SUM+"MD5SUM=\"$MD5SUM\""} \
${SHA256SUM+"SHA256SUM=\"$SHA256SUM\""} \
- ${ADDREQUIRES+"ADDREQUIRES=\"$ADDREQUIRES\""} )"
+ ${ADDREQUIRES+"ADDREQUIRES=\"$ADDREQUIRES\""} \
+ ${DELREQUIRES+"DELREQUIRES=\"$DELREQUIRES\""} )"
unset VERSION OPTIONS GROUPADD USERADD \
CONFLICTS \
@@ -603,6 +604,13 @@ function parse_info_and_hints
INFOREQUIRES[$itemid]=""
fi
else
+ # If DELREQUIRES is set, remove those entries from the INFOREQUIRES array
+ if [ -v DELREQUIRES ]; then
+ for DELREQ in ${DELREQUIRES[@]}; do
+ INFOREQUIRES[$itemid]="$(echo ${INFOREQUIRES[$itemid]//$DELREQ/})"
+ done
+ fi
+
# Get rid of %README% silently, and append ADDREQUIRES
INFOREQUIRES[$itemid]="$(echo ${INFOREQUIRES[$itemid]//%README%/} ${ADDREQUIRES})"
fi
--
2.9.0
Hi folks, please forgive the thread bump but it relates to previous discussions here. It's now potentially quite close to a new release and I'm wondering what your priorities are between (a) getting a release done, and (b) doing some requests that I haven't done yet, and (c) any other requests you might have.
First, this keeps coming up again and again
Quote:
Originally Posted by atelszewski
But still, I would prefer to be: 1) given all the reasons for a rebuild, 2) asked if I want to rebuild or mark the package as rebuilt without actually rebuilding.
Quote:
Originally Posted by bassmadrigal
IGNORE=yes|no option within the hintfile. This would tell slackpkg to ignore any changes to that slackbuild and use the previously compiled version
Quote:
Originally Posted by atelszewski
developing SlackBuilds becomes a pain and it boils down to the automatic rebuilds. I would love to see a possibility of preventing rebuilding of a package and marking it as up to date. It would be helpful in situation where you, for example: update the README, update the download URL in the .info, and so on.
Quote:
Originally Posted by slalik
when slackrepo builds a package that already installed, it upgrades it to the newly built version. This is not always good
I think if I make the SKIP= hint non-fatal, it will have the version-freezing effect that you all want, but I haven't yet experimented with it. This seems to be your number one priority, is that correct?
There's now a --preview control argument that shows what would be updated or rebuilt, but doesn't do any builds. It's like a very lazy --dry-run. This might be useful
Quote:
Originally Posted by atelszewski
solution not to rebuild the package after git commit, after the commit, even if the committed SlackBuild is the same as the dirty one, then slackrepo will issue rebuild of it.
I'm close to finishing a solution, but I'm very worried that I'll add lots of new bugs when I release it.
Quote:
Originally Posted by bassmadrigal
Add c++11 override to pragma
When I start looking at -current (still haven't started yet!) I'll consider this (and whatever similar fixes are frequently needed). But really, any scripts that need this are broken, and we need to send the fixes to ponce. You also mention setting arbitrary environment variables: it would definitely be good to do that in hintfiles.
Quote:
Originally Posted by atelszewski
handling of build-time and run-time only dependencies
I've done BUILDTIME=, but not RUNTIME=. The whole concept of run-time only dependencies seems bogus. They still need to be built and kept up to date, and the package that depends on them might need to be updated when they change. The current setup does all that and I don't see another good way of making that happen, at the moment.
Quote:
Originally Posted by atelszewski
handling of circular dependencies
I've fixed the huge bug in circular dependency detection, but I've not added any way of building circular dependencies. I think this can be done (with a new CIRCULAR= hint), but it will need lots of coding and testing.
Quote:
Originally Posted by atelszewski
possibility of having source code tarballs in single/flat location,
I'm going to do a big rewrite of the source repository, but it will take a long time and there will be lots of new bugs
Quote:
Originally Posted by bassmadrigal
it would also be extremely handy to have a /etc/slackrepo/$repo/slackbuilds/ folder that can override files in the regular repo
This is another frequent request and I don't think that the frequent answer ("use your own git branch") is making people happy
The best solution will need a big scary rewrite to do two things -- (1) add a 'local' repo as a first-class repo like SBo, csb etc, and (2) integrate all the repos so they can share dependencies. Maybe I should stop thinking about the best solution and just give you the worst solution
Quote:
Originally Posted by slalik
'slackrepo update' doesn't want to work with my local repository directly (my guess is that slackrepo contructed to work with a remote repository)
I think this could be solved with a new start hook, but it will need some experiments before it's ready to release.
-----
So anyway, if you want to tell me what your priorities are, and to remind me of other good ideas that I've forgotten, this is your chance
Last thing -- THANKS FOR ALL THE ENCOURAGEMENT AND THANKS FOR THE GREAT NEW IDEAS
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
