yay/main.go

226 lines
5.1 KiB
Go
Raw Normal View History

2018-09-15 17:17:03 +00:00
package main // import "github.com/Jguer/yay"
2018-03-22 15:46:48 +00:00
import (
2018-03-22 16:39:27 +00:00
"encoding/json"
"fmt"
2018-03-22 15:46:48 +00:00
"os"
"path/filepath"
"strings"
pacmanconf "github.com/Morganamilo/go-pacmanconf"
2019-04-23 15:53:20 +00:00
alpm "github.com/Jguer/go-alpm"
2018-03-22 15:46:48 +00:00
)
func setPaths() error {
if configHome = os.Getenv("XDG_CONFIG_HOME"); configHome != "" {
configHome = filepath.Join(configHome, "yay")
} else if configHome = os.Getenv("HOME"); configHome != "" {
configHome = filepath.Join(configHome, ".config/yay")
2018-03-22 15:46:48 +00:00
} else {
return fmt.Errorf("XDG_CONFIG_HOME and HOME unset")
2018-03-22 15:46:48 +00:00
}
if cacheHome = os.Getenv("XDG_CACHE_HOME"); cacheHome != "" {
cacheHome = filepath.Join(cacheHome, "yay")
} else if cacheHome = os.Getenv("HOME"); cacheHome != "" {
cacheHome = filepath.Join(cacheHome, ".cache/yay")
2018-03-22 15:46:48 +00:00
} else {
return fmt.Errorf("XDG_CACHE_HOME and HOME unset")
2018-03-22 15:46:48 +00:00
}
configFile = filepath.Join(configHome, configFileName)
vcsFile = filepath.Join(cacheHome, vcsFileName)
return nil
2018-03-22 15:46:48 +00:00
}
func initConfig() error {
cfile, err := os.Open(configFile)
if !os.IsNotExist(err) && err != nil {
return fmt.Errorf("Failed to open config file '%s': %s", configFile, err)
}
2018-03-22 15:46:48 +00:00
defer cfile.Close()
if !os.IsNotExist(err) {
decoder := json.NewDecoder(cfile)
if err = decoder.Decode(&config); err != nil {
return fmt.Errorf("Failed to read config '%s': %s", configFile, err)
2018-03-22 15:46:48 +00:00
}
}
return nil
}
func initVCS() error {
vfile, err := os.Open(vcsFile)
if !os.IsNotExist(err) && err != nil {
return fmt.Errorf("Failed to open vcs file '%s': %s", vcsFile, err)
}
defer vfile.Close()
if !os.IsNotExist(err) {
decoder := json.NewDecoder(vfile)
if err = decoder.Decode(&savedInfo); err != nil {
return fmt.Errorf("Failed to read vcs '%s': %s", vcsFile, err)
2018-03-22 15:46:48 +00:00
}
}
return nil
2018-03-22 15:46:48 +00:00
}
func initHomeDirs() error {
if _, err := os.Stat(configHome); os.IsNotExist(err) {
if err = os.MkdirAll(configHome, 0755); err != nil {
return fmt.Errorf("Failed to create config directory '%s': %s", configHome, err)
2018-03-22 15:46:48 +00:00
}
} else if err != nil {
return err
}
if _, err := os.Stat(cacheHome); os.IsNotExist(err) {
if err = os.MkdirAll(cacheHome, 0755); err != nil {
return fmt.Errorf("Failed to create cache directory '%s': %s", cacheHome, err)
}
} else if err != nil {
return err
2018-03-22 15:46:48 +00:00
}
return nil
}
func initBuildDir() error {
if _, err := os.Stat(config.BuildDir); os.IsNotExist(err) {
if err = os.MkdirAll(config.BuildDir, 0755); err != nil {
return fmt.Errorf("Failed to create BuildDir directory '%s': %s", config.BuildDir, err)
}
} else if err != nil {
return err
}
return nil
2018-03-22 15:46:48 +00:00
}
func initAlpm() error {
var err error
var stderr string
2018-03-22 15:46:48 +00:00
root := "/"
if value, _, exists := cmdArgs.getArg("root", "r"); exists {
root = value
2018-03-22 15:46:48 +00:00
}
pacmanConf, stderr, err = pacmanconf.PacmanConf("--config", config.PacmanConf, "--root", root)
if err != nil {
return fmt.Errorf("%s", stderr)
2018-03-22 15:46:48 +00:00
}
if value, _, exists := cmdArgs.getArg("dbpath", "b"); exists {
pacmanConf.DBPath = value
2018-03-22 15:46:48 +00:00
}
if value, _, exists := cmdArgs.getArg("arch"); exists {
pacmanConf.Architecture = value
2018-03-22 15:46:48 +00:00
}
if value, _, exists := cmdArgs.getArg("ignore"); exists {
pacmanConf.IgnorePkg = append(pacmanConf.IgnorePkg, strings.Split(value, ",")...)
2018-03-22 15:46:48 +00:00
}
if value, _, exists := cmdArgs.getArg("ignoregroup"); exists {
pacmanConf.IgnoreGroup = append(pacmanConf.IgnoreGroup, strings.Split(value, ",")...)
2018-03-22 15:46:48 +00:00
}
//TODO
//current system does not allow duplicate arguments
2018-12-19 21:13:46 +00:00
//but pacman allows multiple cachedirs to be passed
2018-03-22 15:46:48 +00:00
//for now only handle one cache dir
2018-12-19 21:13:46 +00:00
if value, _, exists := cmdArgs.getArg("cachedir"); exists {
pacmanConf.CacheDir = []string{value}
2018-03-22 15:46:48 +00:00
}
if value, _, exists := cmdArgs.getArg("gpgdir"); exists {
pacmanConf.GPGDir = value
2018-03-22 15:46:48 +00:00
}
2019-03-05 20:10:04 +00:00
if err := initAlpmHandle(); err != nil {
return err
2018-03-22 15:46:48 +00:00
}
2019-03-04 16:07:04 +00:00
switch value, _, _ := cmdArgs.getArg("color"); value {
case "always":
2018-03-22 15:46:48 +00:00
useColor = true
2019-03-04 16:07:04 +00:00
case "auto":
useColor = isTty()
2019-03-04 16:07:04 +00:00
case "never":
2018-03-22 15:46:48 +00:00
useColor = false
2019-03-04 16:07:04 +00:00
default:
useColor = pacmanConf.Color && isTty()
2018-03-22 15:46:48 +00:00
}
return nil
Separate Pacman upgrade and AUR Upgrade by default Currently When performing a system upgrade, Yay will first refresh the database then perform the repo and AUR upgrade. This allows Yay to add some features such as better batch interaction, showing potential dependency problems before the upgrade starts and combined menus showing AUR and repo upgrades together. There has been discussion that this approach is a bad idea. The main issue people have is that the separation of the database refresh and the upgrade could lead to a partial upgrade if Yay fails between the two stages. Personally I do not like this argument, there are valid reasons to Yay to fail between these points. For example there may be dependency or conflict issues during the AUR upgrade. Yay can detect these before any installing actually starts and exit, just like how pacman will when there are dependency problems. If Yay does fail between these points, for the previously mentioned reasons or even a crash then a simple refresh will not cause a partial upgrade by itself. It is then the user's responsibility to either resolve these issues or instead perform an upgrade using pacman directly. My opinions aside, The discussions on the Arch wiki has reached a decision, this method is not recommended. So to follow the decided best practises this behaviour has been disabled by default. This behaviour can be toggled using the --[no]combinedupgrade flag It should be noted that Yay's upgrade menu will not show repo packages unless --combinedupgrade is used.
2018-06-22 13:44:38 +00:00
}
func initAlpmHandle() error {
var err error
Separate Pacman upgrade and AUR Upgrade by default Currently When performing a system upgrade, Yay will first refresh the database then perform the repo and AUR upgrade. This allows Yay to add some features such as better batch interaction, showing potential dependency problems before the upgrade starts and combined menus showing AUR and repo upgrades together. There has been discussion that this approach is a bad idea. The main issue people have is that the separation of the database refresh and the upgrade could lead to a partial upgrade if Yay fails between the two stages. Personally I do not like this argument, there are valid reasons to Yay to fail between these points. For example there may be dependency or conflict issues during the AUR upgrade. Yay can detect these before any installing actually starts and exit, just like how pacman will when there are dependency problems. If Yay does fail between these points, for the previously mentioned reasons or even a crash then a simple refresh will not cause a partial upgrade by itself. It is then the user's responsibility to either resolve these issues or instead perform an upgrade using pacman directly. My opinions aside, The discussions on the Arch wiki has reached a decision, this method is not recommended. So to follow the decided best practises this behaviour has been disabled by default. This behaviour can be toggled using the --[no]combinedupgrade flag It should be noted that Yay's upgrade menu will not show repo packages unless --combinedupgrade is used.
2018-06-22 13:44:38 +00:00
if alpmHandle != nil {
if err := alpmHandle.Release(); err != nil {
Separate Pacman upgrade and AUR Upgrade by default Currently When performing a system upgrade, Yay will first refresh the database then perform the repo and AUR upgrade. This allows Yay to add some features such as better batch interaction, showing potential dependency problems before the upgrade starts and combined menus showing AUR and repo upgrades together. There has been discussion that this approach is a bad idea. The main issue people have is that the separation of the database refresh and the upgrade could lead to a partial upgrade if Yay fails between the two stages. Personally I do not like this argument, there are valid reasons to Yay to fail between these points. For example there may be dependency or conflict issues during the AUR upgrade. Yay can detect these before any installing actually starts and exit, just like how pacman will when there are dependency problems. If Yay does fail between these points, for the previously mentioned reasons or even a crash then a simple refresh will not cause a partial upgrade by itself. It is then the user's responsibility to either resolve these issues or instead perform an upgrade using pacman directly. My opinions aside, The discussions on the Arch wiki has reached a decision, this method is not recommended. So to follow the decided best practises this behaviour has been disabled by default. This behaviour can be toggled using the --[no]combinedupgrade flag It should be noted that Yay's upgrade menu will not show repo packages unless --combinedupgrade is used.
2018-06-22 13:44:38 +00:00
return err
}
}
2018-03-22 15:46:48 +00:00
2019-02-04 16:56:02 +00:00
if alpmHandle, err = alpm.Initialize(pacmanConf.RootDir, pacmanConf.DBPath); err != nil {
return fmt.Errorf("Unable to CreateHandle: %s", err)
Separate Pacman upgrade and AUR Upgrade by default Currently When performing a system upgrade, Yay will first refresh the database then perform the repo and AUR upgrade. This allows Yay to add some features such as better batch interaction, showing potential dependency problems before the upgrade starts and combined menus showing AUR and repo upgrades together. There has been discussion that this approach is a bad idea. The main issue people have is that the separation of the database refresh and the upgrade could lead to a partial upgrade if Yay fails between the two stages. Personally I do not like this argument, there are valid reasons to Yay to fail between these points. For example there may be dependency or conflict issues during the AUR upgrade. Yay can detect these before any installing actually starts and exit, just like how pacman will when there are dependency problems. If Yay does fail between these points, for the previously mentioned reasons or even a crash then a simple refresh will not cause a partial upgrade by itself. It is then the user's responsibility to either resolve these issues or instead perform an upgrade using pacman directly. My opinions aside, The discussions on the Arch wiki has reached a decision, this method is not recommended. So to follow the decided best practises this behaviour has been disabled by default. This behaviour can be toggled using the --[no]combinedupgrade flag It should be noted that Yay's upgrade menu will not show repo packages unless --combinedupgrade is used.
2018-06-22 13:44:38 +00:00
}
2019-03-05 20:10:04 +00:00
if err := configureAlpm(pacmanConf); err != nil {
return err
}
Separate Pacman upgrade and AUR Upgrade by default Currently When performing a system upgrade, Yay will first refresh the database then perform the repo and AUR upgrade. This allows Yay to add some features such as better batch interaction, showing potential dependency problems before the upgrade starts and combined menus showing AUR and repo upgrades together. There has been discussion that this approach is a bad idea. The main issue people have is that the separation of the database refresh and the upgrade could lead to a partial upgrade if Yay fails between the two stages. Personally I do not like this argument, there are valid reasons to Yay to fail between these points. For example there may be dependency or conflict issues during the AUR upgrade. Yay can detect these before any installing actually starts and exit, just like how pacman will when there are dependency problems. If Yay does fail between these points, for the previously mentioned reasons or even a crash then a simple refresh will not cause a partial upgrade by itself. It is then the user's responsibility to either resolve these issues or instead perform an upgrade using pacman directly. My opinions aside, The discussions on the Arch wiki has reached a decision, this method is not recommended. So to follow the decided best practises this behaviour has been disabled by default. This behaviour can be toggled using the --[no]combinedupgrade flag It should be noted that Yay's upgrade menu will not show repo packages unless --combinedupgrade is used.
2018-06-22 13:44:38 +00:00
alpmHandle.SetQuestionCallback(questionCallback)
2018-07-26 12:35:19 +00:00
alpmHandle.SetLogCallback(logCallback)
return nil
2018-03-22 15:46:48 +00:00
}
func exitOnError(err error) {
2018-03-22 15:46:48 +00:00
if err != nil {
if str := err.Error(); str != "" {
fmt.Fprintln(os.Stderr, str)
}
cleanup()
os.Exit(1)
2018-03-22 15:46:48 +00:00
}
}
2018-03-22 15:46:48 +00:00
func cleanup() int {
if alpmHandle != nil {
if err := alpmHandle.Release(); err != nil {
fmt.Fprintln(os.Stderr, err)
return 1
}
2018-03-22 15:46:48 +00:00
}
return 0
}
2018-03-22 15:46:48 +00:00
func main() {
2019-03-05 08:08:37 +00:00
if os.Geteuid() == 0 {
fmt.Fprintln(os.Stderr, "Please avoid running yay as root/sudo.")
2018-03-22 15:46:48 +00:00
}
exitOnError(setPaths())
config = defaultSettings()
exitOnError(initHomeDirs())
exitOnError(initConfig())
exitOnError(cmdArgs.parseCommandLine())
2018-09-04 22:05:35 +00:00
if shouldSaveConfig {
config.saveConfig()
}
config.expandEnv()
exitOnError(initBuildDir())
exitOnError(initVCS())
exitOnError(initAlpm())
exitOnError(handleCmd())
os.Exit(cleanup())
2018-03-22 15:46:48 +00:00
}