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.
This is very interesting -- I was thinking about maybe making the msb packages (http://slackware.org.uk/msb/) compatible with slackpkg+ but I'm not sure what exactly needs to be changed. And it also looks like we have to separate copies of GPG.TXT, FILELIST.TXT and other metadata type files duplicated in each architecture's directory?
Edit: We already use Eric's gen_repo script but any suggestions on best practice for repo layout in regards to slackpkg+ would be appreciated. Thanks.
I had the same discussion with kikinovak for his MLED repository. Using my gen_repos_files.sh script you basically have two options:
Create separate ChangeLog.txt for each architecture (so, one goes into msb/14.0/x86/ and another goes into msb/14.0/x86 _64/) and you run the gen_repos_files.sh script twice - handle each repository separately. This is what kikinovak does with his MLED/MLES repositories.
Create a single ChangeLog.txt in the root of your repository tree (inside msb/) and then use the "REPO_SUBDIRS" variable inside the script to tell the script to generate separate FILELIST.TXT MANIFEST.TXT PACKAGES.TXT etc... files in each of those subdirectories, making them useable with slackpkg+ . In your case it would probably look like 'REPO_SUBDIRS="14.0/x86 14.0/x86_64"'. This is how I do it with my multilib repository.
Remember that you can put the configuration variables in a separate file instead of editing the script. Point the USERDEFS environment variable to that file when calling the script.
Yes, this is the best.
However slackpkg+ does support the multiarch repositories (during update slackpkg+ skip packages that are not for the running platform).
GPG-KEY file MUST to be at the same level of CHECKSUMS.md5
so if you want to create two repositories (for x86 and x86_64) you need to duplicate that file.
@zerouno, I modified our msb repo per the previous posts and things are showing up in slackpkg fine but I'm getting GPG errors when trying to install a package. And when I go into one of the subdirectories like http://slackware.org.uk/msb/14.0/x86_64/ and run 'md5sum -c CHECKSUMS.md5 | less' it also gives errors and says it can't find the packages listed but they are there. I'm missing something simple, I'm sure.
Here is relevant excerpt from /etc/slackpkg/slackpkgplus.conf:
Just a small suggestion. Can AlienBob when he compiles packages for his Ktown repository modify his scripts so the packages would end something different than alien. maybe alienkde or alienktown. it would be mush easier to blacklist packages from ktown not to be upgraded using slackpkg+.
Just a small suggestion. Can AlienBob when he compiles packages for his Ktown repository modify his scripts so the packages would end something different than alien. maybe alienkde or alienktown. it would be mush easier to blacklist packages from ktown not to be upgraded using slackpkg+.
I think the ktown packages are outside the "alienbob" repository, so they should not be upgraded by slackpkg+
And it's a shame
edit CHECKSUMS.md5 and drop all md5 row except ANNOUNCE.14_0 (the first):
Code:
These are the MD5 message digests for the files in this directory.
If you want to test your files, use 'md5sum' and compare the values to
the ones listed here.
To test all these files, use this command:
tail +13 CHECKSUMS.md5 | md5sum -c --quiet - | less
'md5sum' can be found in the GNU coreutils package on ftp.gnu.org in
/pub/gnu, or at any GNU mirror site.
MD5 message digest Filename
2da2c97473fd60413c84b99a003e661c ./ANNOUNCE.14_0
Code:
$ md5sum -c CHECKSUMS.md5..
md5sum: ./ANNOUNCE.14_0: No such file or directory
./ANNOUNCE.14_0: FAILED open or read
md5sum: WARNING: 12 lines are improperly formatted
md5sum: WARNING: 1 listed file could not be read
md5sum search "<space>./ANNOUNCE.14_0"
The header introduce an anomaly.
Official CHECKSUMS.md5 ask for "tail +13 CHECKSUMS.md5 | md5sum -c --quiet - | less" to check
Code:
$ tail +13 CHECKSUMS.md5.. | md5sum -c -
./ANNOUNCE.14_0: OK
Insert some space before the word 'site' (line 10)
Code:
These are the MD5 message digests for the files in this directory.
If you want to test your files, use 'md5sum' and compare the values to
the ones listed here.
To test all these files, use this command:
tail +13 CHECKSUMS.md5 | md5sum -c --quiet - | less
'md5sum' can be found in the GNU coreutils package on ftp.gnu.org in
/pub/gnu, or at any GNU mirror site.
MD5 message digest Filename
2da2c97473fd60413c84b99a003e661c ./ANNOUNCE.14_0
the check generate a warning, but does not fails.
Code:
$ md5sum -c CHECKSUMS.md5
./ANNOUNCE.14_0: OK
md5sum: WARNING: 12 lines are improperly formatted
I think the ktown packages are outside the "alienbob" repository, so they should not be upgraded by slackpkg+
And it's a shame
But slackpkg tries to upgrade Ktown packages with ones from the stock distribution. An if the you blacklist them not to be checked by slackpkg you also blacklist all Alienbob packages, because of blacklisting "[0-9]alien", so you need to blacklist each of Ktown packages by name.
But slackpkg tries to upgrade Ktown packages with ones from the stock distribution. An if the you blacklist them not to be checked by slackpkg you also blacklist all Alienbob packages, because of blacklisting "[0-9]alien", so you need to blacklist each of Ktown packages by name.
My point is: if the ktown is not part of the alienbob repository, it will not be managed by slackpkg+, so you will have to install them manually if you want them in your slackware.
Since you are already manually installing them, it would be of no consequence to you if you add "kde" to the slackpkg blacklist.
This way, slackpkg+ will not try to "upgrade" the ktown packages to the official slackware kde packages.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.