yay/main.go

213 lines
4.9 KiB
Go
Raw Normal View History

2018-03-22 15:46:48 +00:00
package main
import (
2018-03-22 16:39:27 +00:00
"encoding/json"
"fmt"
2018-03-22 15:46:48 +00:00
"os"
"path/filepath"
"strings"
alpm "github.com/jguer/go-alpm"
)
func setPaths() error {
if _configHome, set := os.LookupEnv("XDG_CONFIG_HOME"); set {
if _configHome == "" {
return fmt.Errorf("XDG_CONFIG_HOME set but empty")
}
2018-06-05 13:14:49 +00:00
configHome = filepath.Join(_configHome, "yay")
} else if _configHome, set := os.LookupEnv("HOME"); set {
if _configHome == "" {
return fmt.Errorf("HOME set but empty")
}
2018-06-05 13:14:49 +00:00
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, set := os.LookupEnv("XDG_CACHE_HOME"); set {
if _cacheHome == "" {
return fmt.Errorf("XDG_CACHE_HOME set but empty")
}
cacheHome = filepath.Join(_cacheHome, "yay")
} else if _cacheHome, set := os.LookupEnv("HOME"); set {
if _cacheHome == "" {
return fmt.Errorf("XDG_CACHE_HOME set but empty")
}
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 {
2018-03-22 15:46:48 +00:00
defaultSettings(&config)
if _, err := os.Stat(configFile); os.IsNotExist(err) {
if err = os.MkdirAll(filepath.Dir(configFile), 0755); err != nil {
return fmt.Errorf("Unable to create config directory:\n%s\n"+
2018-03-22 15:46:48 +00:00
"The error was:\n%s", filepath.Dir(configFile), err)
}
// Save the default config if nothing is found
return config.saveConfig()
} else if err != nil {
return err
}
cfile, err := os.OpenFile(configFile, os.O_RDWR|os.O_CREATE, 0644)
if err != nil {
return fmt.Errorf("Error reading config: %s\n", err)
}
defer cfile.Close()
decoder := json.NewDecoder(cfile)
if err = decoder.Decode(&config); err != nil {
return fmt.Errorf("Error reading config: %s",
err)
}
if _, err = os.Stat(config.BuildDir); os.IsNotExist(err) {
if err = os.MkdirAll(config.BuildDir, 0755); err != nil {
return fmt.Errorf("Unable to create BuildDir directory:\n%s\n"+
"The error was:\n%s", config.BuildDir, err)
2018-03-22 15:46:48 +00:00
}
}
return err
2018-03-22 15:46:48 +00:00
}
func initVCS() error {
if _, err := os.Stat(vcsFile); os.IsNotExist(err) {
if err = os.MkdirAll(filepath.Dir(vcsFile), 0755); err != nil {
return fmt.Errorf("Unable to create vcs directory:\n%s\n"+
2018-03-22 15:46:48 +00:00
"The error was:\n%s", filepath.Dir(configFile), err)
}
} else if err != nil {
return err
}
vfile, err := os.OpenFile(vcsFile, os.O_RDONLY|os.O_CREATE, 0644)
if err != nil {
return err
2018-03-22 15:46:48 +00:00
}
defer vfile.Close()
decoder := json.NewDecoder(vfile)
_ = decoder.Decode(&savedInfo)
return nil
2018-03-22 15:46:48 +00:00
}
func initAlpm() error {
var err error
2018-03-22 15:46:48 +00:00
if alpmConf, err = readAlpmConfig(config.PacmanConf); err != nil {
return fmt.Errorf("Unable to read Pacman conf: %s", err)
2018-03-22 15:46:48 +00:00
}
if value, _, exists := cmdArgs.getArg("dbpath", "b"); exists {
2018-03-22 15:46:48 +00:00
alpmConf.DBPath = value
}
if value, _, exists := cmdArgs.getArg("root", "r"); exists {
2018-03-22 15:46:48 +00:00
alpmConf.RootDir = value
}
if value, _, exists := cmdArgs.getArg("arch"); exists {
2018-03-22 15:46:48 +00:00
alpmConf.Architecture = value
}
if value, _, exists := cmdArgs.getArg("ignore"); exists {
2018-03-22 15:46:48 +00:00
alpmConf.IgnorePkg = append(alpmConf.IgnorePkg, strings.Split(value, ",")...)
}
if value, _, exists := cmdArgs.getArg("ignoregroup"); exists {
2018-03-22 15:46:48 +00:00
alpmConf.IgnoreGroup = append(alpmConf.IgnoreGroup, strings.Split(value, ",")...)
}
//TODO
//current system does not allow duplicate arguments
//but pacman allows multiple cachdirs to be passed
//for now only handle one cache dir
if value, _, exists := cmdArgs.getArg("cachdir"); exists {
2018-03-22 15:46:48 +00:00
alpmConf.CacheDir = []string{value}
}
if value, _, exists := cmdArgs.getArg("gpgdir"); exists {
2018-03-22 15:46:48 +00:00
alpmConf.GPGDir = value
}
if err = initAlpmHandle(); err != nil {
return err
2018-03-22 15:46:48 +00:00
}
if value, _, _ := cmdArgs.getArg("color"); value == "always" || value == "auto" {
2018-03-22 15:46:48 +00:00
useColor = true
} else if value == "never" {
useColor = false
} else {
useColor = alpmConf.Options&alpm.ConfColor > 0
}
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
if alpmHandle, err = alpmConf.CreateHandle(); 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
}
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.Println(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.Println(err)
return 1
}
2018-03-22 15:46:48 +00:00
}
return 0
}
2018-03-22 15:46:48 +00:00
func main() {
if 0 == os.Geteuid() {
fmt.Println("Please avoid running yay as root/sudo.")
2018-03-22 15:46:48 +00:00
}
exitOnError(cmdArgs.parseCommandLine())
exitOnError(setPaths())
exitOnError(initConfig())
cmdArgs.extractYayOptions()
exitOnError(initVCS())
exitOnError(initAlpm())
exitOnError(handleCmd())
os.Exit(cleanup())
2018-03-22 15:46:48 +00:00
}