You are not logged in.
So I created a repo, and I'm able to install packages on it. The problem I have is when I make changes to a program and repackage it and place it into the repo. Pacman doesn't seem to detect the change.
I type
pacman -Syu package_name
and pacman claims the package is up to date when it clearly is not even on the server anymore. Any advice?
Offline
Look at "pacman -Sl <repo>" to see what version is in the repo. Does that match what you expect?
The output of "pacman --debug -Syu package_name" would also be of help.
Offline
Look at "pacman -Sl <repo>" to see what version is in the repo. Does that match what you expect?
The output of "pacman --debug -Syu package_name" would also be of help.
As root I typed
pacman -Sl my-repo
And it listed all packages in the repo. The one I have updated however is not what is in the repo. The package I updated in the repo is now at v1.13r when I installed it on the system it was 1.10r which is what the output of
pacman -Sl my-repo
claims.
Offline
How did you update the package in the repo?
Offline
How did you update the package in the repo?
I use
makepkg --sign --key MyKEY
in a directory I have designated for the package. I then cp the .xz amd .sig file to my repo directory. Then I cd into the repo directory and type
repo-add -R -s myrepo.db.tar.gz ./*
Lastly I ssh into my LAMP server and copy the files from the repo stored on my computer to the server.
Offline
repo-add -R -s myrepo.db.tar.gz ./*
I guess you have both the new and old version in that directory? It could be adding the new and then replacing it with the old.
Offline
repo-add -R -s myrepo.db.tar.gz ./*
I guess you have both the new and old version in that directory? It could be adding the new and then replacing it with the old.
Yes and No.
Yes when troubleshooting I thought maybe I should have both old versions and new versions in the repo. That didn't work so I went back to the way I was doing it before. And removed the old versions. Still no luck. Here is the
ls -al
output of my repo
-rw-r--r-- 1 arch arch 998 Feb 14 22:14 myrepo.db
-rw-r--r-- 1 arch arch 310 Feb 14 22:14 myrepo.db.sig
-rw-r--r-- 1 arch arch 998 Feb 14 22:14 myrepo.db.tar.gz
-rw-r--r-- 1 arch arch 310 Feb 14 22:14 myrepo.db.tar.gz.sig
-rw-r--r-- 1 arch arch 1628 Feb 14 22:14 myrepo.files
-rw-r--r-- 1 arch arch 310 Feb 14 22:14 myrepo.sig
-rw-r--r-- 1 arch arch 1628 Feb 14 22:14 myrepo.files.tar.gz
-rw-r--r-- 1 arch arch 310 Feb 14 22:14 myrepo.files.tar.gz.sig
-rw-r--r-- 1 arch arch 52880 Feb 14 22:14 clipit-1.4.3-2-x86_64.pkg.tar.xz
-rw-r--r-- 1 arch arch 81316 Feb 14 22:14 isomaster-1.3.13-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 arch arch 12440 Feb 14 22:14 mypkg-git-v1.0.r13.g04b111c-1-any.pkg.tar.xz
-rw-r--r-- 1 arch arch 310 Feb 14 22:14 mypkg-git-v1.0.r13.g04b111c-1-any.pkg.tar.xz.sig
Offline
It seems though what ever I do I can't seem to get the repo to get pacman to register the new updated package. Does it take time for pacman to register the update once a change has been made?
Offline
Is it actually downloading the new database when you -Syu? If not, could be a timestamp issue with the old one, you'd have to force it with a double y
Offline
The cause of this could be incorrect information in your repo database, has been verified whether that's the case ?
If not, post output of
tar -tvf myrepo.files.tar.gz
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
I got it working but don't know why. Maybe someone can explain why after I go into details of what I did to get it working.
Changed the
repo-add -s -R -v myrepo.db.tar.gz ./*
to
repo-add -R -v myrepo.db.tar.gz ./*
I did this after noticing I get good results when I didn't upload the .sig files to the server. After I did this everything works fine.
My concern is though without having the signatures is that really a good idea, and wouldn't it raise trust concerns for my users?
Offline
Not sure if you've tried starting over (with .sig files all there):
mkdir backup
mv myrepo* backup
repo-add -s myrepo.db.tar.gz *.pkg.*
Last edited by jamespharvey20 (2019-02-16 22:25:14)
Offline
jamespharvey20
I have started over several times. Didn't think of narrowing my wildcards down like you did.
Do you think my hosting provider may have done something on their servers to prevent .sigs from working. Or could it be the hosting provider is using CentOS? Are eithr of these a possible reason for such problems
Offline
I was wondering if giving repo-add the myrepo* stuff could cause problems. Haven't tried it or looked at the source.
I can't imagine the hosting provider really being able to do anything that would selectively screw up .sigs but nothing else. If even possible, it would be fairly difficult for a host machine to do that to a VM.
I doubt this would even cause this either, but did you install Arch from scratch from an ISO? Or, does your hosting provider give you a VM with Arch pre-installed on it? Personally, I'd always install from scratch, and not use their pre-made image. Even if they install it "right", giving up control over partition and filesystem type feels icky.
Offline
I
I doubt this would even cause this either, but did you install Arch from scratch from an ISO? Or, does your hosting provider give you a VM with Arch pre-installed on it? Personally, I'd always install from scratch, and not use their pre-made image. Even if they install it "right", giving up control over partition and filesystem type feels icky.
My hosting provider has nothing to do with my arch linux system. They are primarily for hosting websites and I'm using there storage for repo hosting. Because there systems are CentOS based and they deal with hosting websites, getting any help through them will be fruitless.
My current install of Arch Linux which is also my very first install was using the ISO image downloaded from a US mirror from the Arch Linux website. I used dd to copy it onto a USB flash drive and do to my lack of experience with EFI I have opted out of using EFI with this machine. However I did eventually install an EFI version first on VBox then on another PC.
Offline