* README grammar, spelling, rewording, organizing
- Add "Objectives" section to group objectives.
- Transform Objective/Feature section bullets into action phrases.
- Fix yay/yaourt/etc capitalization. Italicize and follow ArchWiki style.
- Clearly identify the two Install section options with similar wording.
- Reorganize and reword Contributing section.
- Fix wording in last Code Style section sentence.
- Fix misc FAQ wording.
- Use same style for all FAQ issue links.
- Change link in "skipping packages" FAQ item to ArchWiki partial upgrade.
- Fix FAQ aur-only/repo-only cmd example line-spacing.
- Remove yay -Pu example since it is a deprecated (and wrapped) option.
* Fixup remove trailing newline in README file
* Add warning about editing files in vendor/
* Fixup revert italicized project/program names
* Change obj to Yaourt-style interactive srch/inst
* Change obj to Minimal dependencies
* Remove the limit-to-pacman deps feature
* Revert init-install sentence, but add "alternatively"
* Add provide-handling bullet to features
* Revert aur/repo-only FAQ item to one line
* Format cmd line examples similar to man page format
* Revert interface-for-pacman objective
* Mention dep instead of just saying don't touch
* Merge gopath into the build stage
Setting the gopath is more of a note than a step. It is not required and
I would expect most people can simply ignore it.
* Reword dependencies section.
The contributing section should be information and say what dependencies
are needed. There's no need to tell the user how to install them, they
can figure that out themselves.
Also mention git as a dependency.
* Tweak headings and drop numbers
Similar to the last commit. The headings should be
informative "Code Style", not commanding "Check code".
* yay -> Yay
Be more consistent when writing Yay as a name.
* Use ### instead of #### in Contributing
These are real subheadings, #### looks too small.
* Add support section
This message is proving to be more misleading than helpful. For
git+https sources, many hosts seem to always timeout when trying
ls-remote over git:// but then succeed on https://. This leads to
a time out message being displayed even though the URL was queried
successfully on the second try.
Before --needed was left purerly to pacman. The problem with this is
that if a package is not in the cache, it will end up being build just
for pacman to skip over the install.
Now Yay will handle this and skip the build and install if --needed is
used. The inital clone and pkgver bumb is still donw.
The one place this function is used, the caller converts its data to
a map just to getBases will accept it. Instead just allow it to take the
slice to begin with.
There was a possibly that getIncompatible could be broken when working
with split packages. After looking into it, this does not seem to be the
case, as long as we only work with pkgbases.
arch may be overriden inside of a package function. The global arch
array may be 'any' but package_foo could say arch=('x86_64'). If you
were running arm then should yay warn about this?
I have decided the answer is no. This is because makepkg doesn't care.
It would seem makepkg only checks the global arch array. This leads me
to believe that the global array should contain a the required arch.
Therefore the correct way to do the former example would be to declare
the global arch as 'x86_64' and then override package_bar with 'any'.
So all that we should do is properly use formatPkgbase to list all the
packages under the base.
depOrder.Aur contains the order in which AUR packages are to be
installed. While depOrder.bases contains the actual package data
organized by pkgbase.
deoOrder.AUR is kind of counterintuitive, as it only contains one
package from each package base.
For example if you were to install libc++{,abi,experimental},
depOrder.Aur would only contain one of those packages, which one
actually being quite random. depOrder.Bases[pkg.Pkgbase] will then be
looked up and everything under that slice would be installed.
This means that the only real use depOrder.Aur has, is to give the
pkgbase. So to cut out the middleman, lets merge .Aur and .Bases into
a single field.
Doing this has also heped to spot som subtle bugs:
Fix subtle split package errors.
The number menus now correctly list and respect (installed) for bases
that have atleast one of their packages installed.
Entering package names in number menus now always expects the pkgbase
name instead of the random package which happened to make it into .Aur.
--rebuild and --redownload correctly handles split packages.
formatPkgbase is also used more.
Only pass the packages belonging to the desired pkgbase. Before our
entire list of every pkgbase had to be passed, as well as an example
package from the base we are looking for.
This lets use use formatPkgBase easier in other places outside of
install.
Many of the functions in install could also be simplified in a similar
way, although that has not been done in this commit.
Most programs seem to take an empty string as being the same as unset.
Even if they are technically different. This makes it easier to unset
variables via `VARIABLE= yay --foo`.
Split functions out into smaller, more simple chunks. Ensure the correct
order of things.
Before, initConfig() would also create config.BuildDirbefore
the command line flags have been applied, so yay would
try to mkdir what was in the config, ignoring the flag.
