dirty indicates if the repo has uncommited changes or not when building,
so dont hardcode this info.
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
repo-add should only attempt to create the delta file when using the -d
option.
Also adjust a couple of tests to use the "double bracket" syntax.
Signed-off-by: Allan McRae <allan@archlinux.org>
Signed-off-by: Dan McGee <dan@archlinux.org>
Allan, I had no idea you were not listed here. I think you count as an
active developer at the moment. Also, move Aaron to the past contributors
section.
Signed-off-by: Dan McGee <dan@archlinux.org>
This includes info on version comparison that is very similar to the stuff
in the pacman manpage, but also a few vercmp examples, the return values,
and other fun stuff.
Also update the version comparison stuff in the pacman manpage.
Signed-off-by: Dan McGee <dan@archlinux.org>
This makes things consistent with everywhere else we are incorporating the
new optional epoch field. Add a helper function that forms the version
string for you and use it in makepkg where I found 'pkgver.*-.*pkgrel'.
This exposes a few shortcomings in a previous "Override pkgver" patch
(2020e629) in the install package and check if built functions.
Signed-off-by: Dan McGee <dan@archlinux.org>
Instead, go the same route we have always taken with version-release in
libalpm and treat it all as one piece of information. Makepkg is the only
script that knows about epoch as a distinct value; from there on out we will
parse out the components as necessary.
This makes the code a lot simpler as far as epoch handling goes. The
downside here is that we are tossing some compatibility to the wind;
packages using force will have to be rebuilt with an incremented epoch to
keep their special status.
Signed-off-by: Dan McGee <dan@archlinux.org>
Adapting from RPM, follow the [epoch:]version[-release] syntax. We can also
borrow some of their parsing code for our purposes (thanks!). Add some new
tests to our vercmp shell script tester for epoch comparisons, and then make
the code work with these newfangled epoch specifiers.
Signed-off-by: Dan McGee <dan@archlinux.org>
Since it is the same string. Done with some bash looping and sed magic.
for src in po/*.po; do
echo $src
newtrans=$(grep -A1 "msgid.*$1" $src | tail -n1)
newtrans=${newtrans//\\/\\\\}
echo "$newtrans"
fname=${src##*/}
dest=lib/libalpm/po/$fname
sed -i -e "/msgid.*$1/{N; s/msgstr.*$/$newtrans/}" $dest
done
Signed-off-by: Dan McGee <dan@archlinux.org>
In most (all?) cases, we will process all files for a given sync database
entry sequentially. The code currently does an _alpm_pkg_find() for every
file in the database, but we had the "current" package readily available.
Shift some local variables around a bit to expose this to sync_db_read() and
use it if the package is the correct one.
On my system, this cuts calls to _alpm_pkg_find() from 20,769 to 10,349
calls during a -Qu operation, and results in a ~30% speedup of the same
operation (0.35 sec -> 0.27 sec). This benefit should be apparent anywhere
we read in the full contents of the sync databases.
Signed-off-by: Dan McGee <dan@archlinux.org>
We don't need to create a temporary copy of the string if we are smart with
our pointer manipulation and string copying. This saves a bunch of string
duplication during database parsing, both local and sync.
Signed-off-by: Dan McGee <dan@archlinux.org>
Remove the need for an unconditional string duplication by using pointer
arithmetic instead, and strndup() instead of an unspecified-length strdup().
This should reduce memory churn a fair amount as this is called pretty
frequently during database loads.
Signed-off-by: Dan McGee <dan@archlinux.org>
We haven't tweaked this in a while, but some of the old stuff seems to no
longer be necessary and there are a few new things we should add.
Signed-off-by: Dan McGee <dan@archlinux.org>
Confirming the current behavior. And yes, the error message is still no
better than it was when this was reported 3.5 years ago.
Signed-off-by: Dan McGee <dan@archlinux.org>
When installing packages from a file, the integrity check count
stays at (0/x) complete. This ensures it is bumped to (x/x) at
the end of the process.
Signed-off-by: Dan McGee <dan@archlinux.org>
It is pretty annoying to get one, fix it, and then get another. We should be
able to continue on through most of the sanity checks in one go so the user
gets all the error messages at once.
Also ensure $pkgbase is defined by the time we call this function;
previously we printed nothing where a package name should have been due to
this oversight.
Signed-off-by: Dan McGee <dan@archlinux.org>
I tried to move things around here when testing and did a bit too much; the
warning message always showed regardless of delta inclusion in the call. Fix
it so we only warn if we have a filename, but the file couldn't be located.
Signed-off-by: Dan McGee <dan@archlinux.org>
This is essentially a backport/cherry-pick of commit 33240e87b9 from
master, but has to be done by hand because the DB format has diverged. Read
more in the commit message used there, which follows.
Due to the way we funk around with package data loading, we had a condition
where the filelist got doubled up because it was loaded twice.
Packages are originally loaded with INFRQ_BASE. In an upgrade/sync, the
package is checked for file conflicts next, leaving us in an "INFRQ_BASE |
INFRQ_FILES" state. Later, when committing a single package, we have an
explicit call to _alpm_local_db_read() with INFRQ_ALL as the level. Because
the package's level did not match this, we skipped over our previous "does
the incoming level match where I'm at" shortcut, and continued to load
things again, because of a lack of fine-grained checking for each of DESC,
FILES, and INSTALL.
The end result is we loaded the filelist twice, causing our remove logic to
iterate twice over the installed files, spewing a bunch of "cannot find file
X" messages.
Fix the problem by doing a bit more bitmasking logic throughout the load
method, and also fix the sanity check at the beginning of the function- this
should *only* be used for local packages as opposed to the "not a package"
check that was there before.
Signed-off-by: Dan McGee <dan@archlinux.org>
This will prevent duplicates, which we had plenty of once I made a few tests
that had a list of files greater than the normal two. The previous logic was
not working quite right.
Signed-off-by: Dan McGee <dan@archlinux.org>
(cherry picked from commit 0d4dd09993)
After all the debate as to what to do on maint, we are going to end up just
incorporating epoch into the version string, so we don't need this separate
field at all. Revert commit 5c8083baa4 and also kill the force flag we were
recording here as well.
Signed-off-by: Dan McGee <dan@archlinux.org>
Due to the way we funk around with package data loading, we had a condition
where the filelist got doubled up because it was loaded twice.
Packages are originally loaded with INFRQ_BASE. In an upgrade/sync, the
package is checked for file conflicts next, leaving us in an "INFRQ_BASE |
INFRQ_FILES" state. Later, when committing a single package, we have an
explicit call to _alpm_local_db_read() with INFRQ_ALL as the level. Because
the package's level did not match this, we skipped over our previous "does
the incoming level match where I'm at" shortcut, and continued to load
things again, because of a lack of fine-grained checking for each of DESC,
FILES, and INSTALL.
The end result is we loaded the filelist twice, causing our remove logic to
iterate twice over the installed files, spewing a bunch of "cannot find file
X" messages.
Fix the problem by doing a bit more bitmasking logic throughout the load
method, and also fix the sanity check at the beginning of the function- this
should *only* be used for local packages as opposed to the "not a package"
check that was there before.
A debug log message was added to upgraderemove as well to match the one
already in the normal remove codepath.
Signed-off-by: Dan McGee <dan@archlinux.org>
libarchive eventually calls it anyway, but backtraces make a lot more sense
if we call it, as well as matching our precedent from alpm_pkg_load().
Signed-off-by: Dan McGee <dan@archlinux.org>
This is helpful anyway to the user, and should also be helpful to us if we
see problems cropping up in the check during development.
Also add a missing ->used = 0 initialization in the code path less taken.
Signed-off-by: Dan McGee <dan@archlinux.org>
Although they won't be the same in the gettext catalog because of the '\n'
we should still use the same text.
Signed-off-by: Dan McGee <dan@archlinux.org>
This can take a while too, and it is really easy to add the necessary
callback stuff for adding a progressbar.
Signed-off-by: Dan McGee <dan@archlinux.org>
These were just two small things I came across today and found could be
fixed or helpful, so I've added them and I'm not sure what else to bundle
them with. commit_count++
Signed-off-by: Dan McGee <dan@archlinux.org>
These are probably useful anyway, but also exposed the double file list bug
that will be fixed in a later commit.
Signed-off-by: Dan McGee <dan@archlinux.org>
This will prevent duplicates, which we had plenty of once I made a few tests
that had a list of files greater than the normal two. The previous logic was
not working quite right.
Signed-off-by: Dan McGee <dan@archlinux.org>
Rather than explicit cd calls, we can use the directory stack to our
advantage. This also removes the need to store and restore $startdir, so
kill the variable entirely.
Signed-off-by: Dan McGee <dan@archlinux.org>
