You are not logged in.
I switched from the stable version of an app to the git version. I decided to remove the stable version and just use the git version. So I pacman -R the stable version but I still need the dependencies for the git branch. How can i keep them from being removed by pacman?
Last edited by mamamia88 (2013-03-28 15:35:06)
Offline
if the dependencies are required by the git version, then they should remain on the system if you have installed the git version already.
If you plan to install the git version after removing the stable version, the dependencies will be re-installed during the install of the git version. Let pacman worry about what dependencies are needed.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
if the dependencies are required by the git version, then they should remain on the system if you have installed the git version already.
If you plan to install the git version after removing the stable version, the dependencies will be re-installed during the install of the git version. Let pacman worry about what dependencies are needed.
I was running the stable version via yaourt. I cloned the git version and run it from a binary contained in the git directory. Pacman thinks that packages aren't required because I removed the package that they where dependencies for. I just want to skip those packages so i can remove actual orphans without having pacman remove these packages which pacman thinks aren't required but are. Is there a way to set that up like that?
Last edited by mamamia88 (2013-03-28 15:03:30)
Offline
so you are saying that you installed from source ? or you used a PKGBUILD which downloads and builds the app from source. In the latter case, pacman knows about the dependencies for the app etc.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
so you are saying that you installed from source ?
I didn't install anything really. I just cloned from git and run the binary from the source directory. But I still need the couple packages as dependencies that were left over from previous install
Offline
Adapt the PKGBUILD for the stable version to build from git instead ?
Incase you don't want to do that, look up the --asexplicit flag of pacman.
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
Can't you just change the way those couple packages were installed?
Look into --asexplicit flag for pacman
........and this is getting highly confusing without you actually naming the packages (this package, git version, couple packages...gah!! even I am confused now)
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Can't you just change the way those couple packages were installed?
Look into --as-explicit flag for pacman
........and this is getting highly confusing without you actually naming the packages (this package, git version, couple packages...gah!! even I am confused now)
The package is gpodder. Basically git gives you a directory containining the source as well as a binary file to run the app. But in order for this to be useful you need to have the dependencies on your system. I had originally installed the regular main line version via yaourt but decided i wanted to stay up to date with the master branch so that's what I'm using now. It's just that pacman recognizes a couple of dependencies as orphans.
Offline
so just do a
pacman -S --asexplicit <dependency1> <dependency2>
or better yet, create a PKGBUILD, that will pull the source from git, build the application and install it. You can even submit it to AUR then, if its not already there.
or even better and easier, install this package from aur which does exactly what you want but also makes sure that pacman is aware of it (basically the second option I gave above, but its already done for you) :: https://aur.archlinux.org/packages/?O=0&K=gpodder-git
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Does this not solve the issue: https://aur.archlinux.org/packages/gpodder-git/ ?
Edit: Bah....
Last edited by skanky (2013-03-28 15:20:09)
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
--asexplicit seems to have done the trick thanks everybody
Offline
Does this not solve the issue: https://aur.archlinux.org/packages/gpodder-git/ ?
I'm sure I could use that package just not sure how I would keep it up to date. I subscribe to the rss feed for the github page on google reader. I set up a script that runs git pull before starting the app. Doesn't look like that package has been updated in quite some time
Offline
Bah...'s right !!!
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
skanky wrote:Bah...'s right !!!
just curious for packages like that how do you update them? aren't you dependent on the maintainer for merging git pulls?
Offline
skanky wrote:Does this not solve the issue: https://aur.archlinux.org/packages/gpodder-git/ ?
I'm sure I could use that package just not sure how I would keep it up to date. I subscribe to the rss feed for the github page on google reader. I set up a script that runs git pull before starting the app. Doesn't look like that package has been updated in quite some time
Have you looked at what the PKGBUILD does, it actually pulls from git before building it. the difference is that your aur helper would know about the updates when the maintainer updates the pkgrel. then you would get notification and it would update the package for you.
After you aur helper has finished, pacman now knows about all the dependencies etc for the package, which means it can easily uninstall when required and can provide other information about the package like -Qi or -Qs etc.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Inxsible wrote:skanky wrote:Bah...'s right !!!
just curious for packages like that how do you update them? aren't you dependent on the maintainer for merging git pulls?
the git pull happens on your machine... so you are the one doing the git pull. if at any time you feel that an important feature has been added by upstream to git, you can simply use your aur helper to re-install the package and it will get the latest from git and install it.
if the maintainer is fast enough.... he would simply update the pkgrel and that way you'd get a notification that you can update
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
mamamia88 wrote:Inxsible wrote:Bah...'s right !!!
just curious for packages like that how do you update them? aren't you dependent on the maintainer for merging git pulls?
the git pull happens on your machine... so you are the one doing the git pull. if at any time you feel that an important feature has been added by upstream to git, you can simply use your aur helper to re-install the package and it will get the latest from git and install it.
if the maintainer is fast enough.... he would simply update the pkgrel and that way you'd get a notification that you can update
huh well that seems easy enough. seems like the maintainer hasn't touched it in over 2 years though. i find it easier just to create a single launcher and run git pull in the source directory than to reinstall all the time but thanks for the info.
Offline
huh well that seems easy enough. seems like the maintainer hasn't touched it in over 2 years though. i find it easier just to create a single launcher and run git pull in the source directory than to reinstall all the time but thanks for the info.
Yes, that's because the package hasn't needed to be updated in over two years. The package does the same thing now since it was first created: Checkout the latest version of the code from the git repository and build and install the binary.
But, of course, you're welcome to do it however you want on your computer.
Offline
mamamia88 wrote:huh well that seems easy enough. seems like the maintainer hasn't touched it in over 2 years though. i find it easier just to create a single launcher and run git pull in the source directory than to reinstall all the time but thanks for the info.
Yes, that's because the package hasn't needed to be updated in over two years. The package does the same thing now since it was first created: Checkout the latest version of the code from the git repository and build and install the binary.
But, of course, you're welcome to do it however you want on your computer.
True it would just require me to change the pkgrel everytime i wanted to update? And how would I know it's time to change the pkgrel? I would have to check github anyway. Wonder if there is a way to write a script that checks git for new stuff then automatically edits pkgrel and uploads to the AUR. Just seems like more work than running git pull. Especially when it has to build with every git change. This way I'm not building anything just downloading the new stuff and restarting the app .
Offline
You don't need to touch the pkgrel. In my opinion (and the CVS package guidelines have no clear rule about this), pkgrel should only be bumped up if you make multiple binary-altering changes to the PKGBUILD (e.g. changing configure flags) in the same day. The initial change should change the pkgver to today's date (formatted as YYYYMMDD), and any subsequent changes in the same day should bump the pkgrel up by 1. The next time you alter the PKGBUILD on another day, you should change the pkgver to the date, and reset the pkgrel to 1.
Of course, if you're not maintaining a -git package in the AUR, you can do whatever you want with the pkgver/pkgrel.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Online
You don't need to touch the pkgrel. In my opinion (and the CVS package guidelines have no clear rule about this), pkgrel should only be bumped up if you make multiple binary-altering changes to the PKGBUILD (e.g. changing configure flags) in the same day. The initial change should change the pkgver to today's date (formatted as YYYYMMDD), and any subsequent changes in the same day should bump the pkgrel up by 1. The next time you alter the PKGBUILD on another day, you should change the pkgver to the date, and reset the pkgrel to 1.
Of course, if you're not maintaining a -git package in the AUR, you can do whatever you want with the pkgver/pkgrel.
OK that makes sense. So in order to use that package on the AUR I would have to reinstall with new commits every time there was a commit? So if the package maintainer doesn't update the date on the pkgbuild then it's up to the user to manually check for commits all the time and reinstall? Project seems too active for that but thanks. Is there a way to point yaourt to a local pkgbuild and just have the pkgbuild change dates every day? So that when I yaourt -Syua it updates on a daily basis? And maybe if there are no commits on that particular day then to skip it? That would probably be idea.
Last edited by mamamia88 (2013-03-28 16:30:44)
Offline
So in order to use that package on the AUR I would have to reinstall with new commits every time there was a commit?
You can do it like that if you want, and/or require truly bleeding-edge software, or you can just make a habit of rebuilding the package once a week or something. No matter when you, the end user, rebuild a -git package, you'll always get the most up-to-date code from the repository, and the resultant package will have the date you built the package as the pkgver, so you can tell what date you last built the package at a glance (or you can check with pacman -Qi).
EDIT: If you're using yaourt, I believe that you can pass the --devel flag to have it rebuild all your CVS packages, though yaourt will not store the git clone between reboots by default, so you'll be cloning the entire repository each time, you're better off using makepkg by itself.
Last edited by WorMzy (2013-03-28 16:33:48)
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Online
So in order to use that package on the AUR I would have to reinstall with new commits every time there was a commit? So if the package maintainer doesn't update the date on the pkgbuild then it's up to the user to manually check for commits all the time and reinstall? Project seems too active for that but thanks.
What? Wait. I still get the feeling that you're not quite understanding how the "-git" packages work in the AUR... Yes, you would have to reinstall "every time there was a commit", but just like you have to do by using git manually. Yes, it's "up to the user to manually check for commits all the time and reinstall", just like you were doing by using git manually.
Here's another way to explain it:
Both this:
$ cd ~/gpodder
$ git pull
$ cp gpodder /usr/bin
and this:
yaourt -S gpodder-git
will give you the same result, with the exception being that, in the latter case, the files are being tracked by pacman (through yaourt).
I think most of the people in this thread are just trying to convince you to use the package manager, which is generally considered a very good thing to use.
Last edited by drcouzelis (2013-03-28 16:50:51)
Offline
mamamia88 wrote:So in order to use that package on the AUR I would have to reinstall with new commits every time there was a commit?
You can do it like that if you want, and/or require truly bleeding-edge software, or you can just make a habit of rebuilding the package once a week or something. No matter when you, the end user, rebuild a -git package, you'll always get the most up-to-date code from the repository, and the resultant package will have the date you built the package as the pkgver, so you can tell what date you last built the package at a glance (or you can check with pacman -Qi).
EDIT: If you're using yaourt, I believe that you can pass the --devel flag to have it rebuild all your CVS packages, though yaourt will not store the git clone between reboots by default, so you'll be cloning the entire repository each time, you're better off using makepkg by itself.
Cool thanks for the in depth explanation. Guess I'm just a little bit obscessive. Right now I have it setup so that I check google reader every mornig and if I see a new commit I close the app and restart it with my custom script that cds to the directory and runs git pull before relaunching the app. That works pretty well so I think I'm gonna stick with that for now. It also doesn't install anything so if i ever stop using the app i can just delete the git folder. It's not the editing the pkgbuild that i'm trying to avoid it's the waiting for the pkg to make and install. Git pull is almost instantaneous.
Offline
It also doesn't install anything so if i ever stop using the app i can just delete the git folder.
WRONG !!
you forgot about the 2 dependencies that you made --asexplicit already ! and its not even been a couple hours. How do you expect to remember about them 7 months down the line?
If you let pacman manage it, it will remove those dependencies when you uninstall the package, thereby leaving you with a cleaner system.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline