February 2010 - Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] don't use old packages to satisfy dependencies
by Henning Garus 12 Feb '10

12 Feb '10

Don't use packages which are updated during the current transaction as dependency providers, when computing needed dependencies in resolvedeps. This could lead to new dependencies not being pulled in, in situations like: foo-1 provides bar baz depends on bar foo-2 does not provide bar anymore baz still depends on bar bar is not pulled in because foo-1 is used to satisfy the dependency Signed-off-by: Henning Garus <henning.garus(a)gmail.com> --- This should fix the "phonon bug". I am not entirely happy with this, because I more or less copy the local db (once more) on every call to resolvedeps. Alternatively one could create a joined list from remove and trans->add and give it to checkdeps as remove parameter. This would do what we want (exclude packages which will be upgraded from the list used to compute already satisfied dependencies in checkdeps), but it feels wrong. lib/libalpm/deps.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c index 46699ac..85d7e24 100644 --- a/lib/libalpm/deps.c +++ b/lib/libalpm/deps.c @@ -600,6 +600,7 @@ int _alpm_resolvedeps(pmdb_t *local, alpm_list_t *dbs_sync, pmpkg_t *pkg, { alpm_list_t *i, *j; alpm_list_t *targ; + alpm_list_t *untouched = NULL; alpm_list_t *deps = NULL; alpm_list_t *packages_copy; @@ -620,11 +621,19 @@ int _alpm_resolvedeps(pmdb_t *local, alpm_list_t *dbs_sync, pmpkg_t *pkg, on that list */ *packages = alpm_list_add(*packages, pkg); + /* Create a list of local packages which can be used to satisfy deps. + * Don't use packages which are updated in the current transaction */ + for(i = _alpm_db_get_pkgcache(local); i; i = i->next) { + if(!alpm_list_find(handle->trans->add, i->data, _alpm_pkg_cmp)) { + untouched = alpm_list_add(untouched, i->data); + } + } + _alpm_log(PM_LOG_DEBUG, "started resolving dependencies\n"); for(i = alpm_list_last(*packages); i; i = i->next) { pmpkg_t *tpkg = i->data; targ = alpm_list_add(NULL, tpkg); - deps = alpm_checkdeps(_alpm_db_get_pkgcache(local), 0, remove, targ); + deps = alpm_checkdeps(untouched, 0, remove, targ); alpm_list_free(targ); for(j = deps; j; j = j->next) { pmdepmissing_t *miss = j->data; @@ -666,6 +675,7 @@ int _alpm_resolvedeps(pmdb_t *local, alpm_list_t *dbs_sync, pmpkg_t *pkg, alpm_list_free_inner(deps, (alpm_list_fn_free)_alpm_depmiss_free); alpm_list_free(deps); } + alpm_list_free(untouched); alpm_list_free(packages_copy); _alpm_log(PM_LOG_DEBUG, "finished resolving dependencies\n"); return(0); -- 1.6.6.1

2 1

Re: [pacman-dev] [arch-general] Error message on mkinitcpio
by Xavier Chantry 12 Feb '10

12 Feb '10

On Thu, Feb 11, 2010 at 10:27 PM, Dan McGee <dpmcgee(a)gmail.com> wrote: > > I think we may have this fixed in pacman-git, but Nagy or Xavier would > know for sure... > That documentation from man PKGBUILD still applies, I don't think we ever considered it as a bug/problem : replaces (array) An array of packages that this package should replace, and can be used to handle renamed/combined packages. For example, if the j2re package is renamed to jre, this directive allows future upgrades to continue as expected even though the package has moved. Sysupgrade is currently the only pacman operation that utilizes this field, a normal sync will not use its value. But now I am wondering if replaces could imply conflicts/provides. Implicit fields means less control and power to the user/packager though.

2 1

Re: [pacman-dev] [arch-dev-public] Warning 2/2: removing kde-unstable; KDE 4.4 in testing
by Xavier Chantry 10 Feb '10

10 Feb '10

On Mon, Feb 1, 2010 at 1:04 PM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > Hi DEVs and TUs, > > I am about to move the first wave of KDE 4.4 RC3 packages into testing. These > will be x86_64 at first; i686 packages might follow later this evening. There > won't be any l10n packages. (they are not needed for testing and rebuild and > we'll save disk space and bandwidth this way) > > The same Information about kde-unstable now apply to testing: > http://wiki.archlinux.org/index.php/DeveloperWiki:KDE#Users Note that the kde- > unstable repository will be removed soon. > > If you update you have to use the following commands as pacman is not able to > resolve the dependencies otherwise: > > % pacman -Sy --asdeps qt > % pacman -Su > Please report this kind of issues to pacman-dev ML or pacman bugtracker in the future :) This limitation was actually not even known to us (at least Nagy and I), and it doesn't seem that we have a pactest for it. This issue might be fixable (at least that specific case), and it might be a pactest that we want to add to the testsuite, to avoid future regressions.

4 6

Re: [pacman-dev] [arch-general] A suggestion for the devs regarding rebuilds
by Xavier Chantry 08 Feb '10

08 Feb '10

On Mon, Jan 11, 2010 at 12:53 AM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On Sun, Jan 10, 2010 at 12:08 PM, Jeff Horelick <jdhore1(a)gmail.com> wrote: >> Hey all, >> >> I have a suggestion to possibly make rebuilds a bit less painful (or >> non-existant). I think this is a good idea because it seems like right now, >> even before there was a new rebuild (ffmpeg/x264) in testing, there's >> already another on the horizon (linjpeg/libpng, and it's a big one) and when >> this isn't the case, there's usually a rebuild, when it leaves testing, >> another rebuild comes in within days and so on. >> >> My suggestion would be to do what Debian does and when there's a library >> release with a new soname, bump the old package and "rename" it (or for new >> packages just do it from the start) and make the package name include the >> soname version (like libjpeg7, libpng12, libtorrent-rasterbar4 and so on) >> and when the soname is bumped upstream, just make libjpeg8 or libpng13 or >> libtorrent-rasterbar5. This does clutter the repos a bit, but it pretty much >> negates the need for rebuilds since (i believe) when the new GNOME for >> example is released, it'll automagically build against libjpeg8 and libpng13 >> instead of the old ones and eventually, almost no packages will be using the >> old ones. Once the package list for a large rebuild like the libpng/libjpeg >> one is down to 3 or 4 items after like 3 months, you can probably rebuild >> them and pull libjpeg7/libpng12 from the repos. > > This is one of the single biggest things I hate about apt based > distros. The libfoo2/libfoo3/libfoo4 cruft. It's needless. > > This doesn't do anything with regards to helping the devs do rebuilds, > because packages still need to be rebuilt. It just allows us to take > our time - something you DON'T want if you're expecting packages to be > up to date. > With every big rebuilds we get new breakage stories. It seems like it's the norm nowadays rather than the exception. I am wondering if it's really only the users that are to blame.. or if Arch is also to blame. Or if Arch was supposed to be an elitist distribution and is victim of its success. More importantly, I am wondering if the sodepends/soprovides proposal would not actually be a more complex solution than the libfoo2/libfoo3/libfoo4 way.

2 1

[pacman-dev] [PATCH] makepkg: only strip files that are writable
by Allan McRae 03 Feb '10

03 Feb '10

Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 5120feb..0ca5e36 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -869,7 +869,7 @@ tidy_install() { if [[ $(check_option strip) = y && -n ${STRIP_DIRS[*]} ]]; then msg2 "$(gettext "Stripping unneeded symbols from binaries and libraries...")" local binary - find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do + find ${STRIP_DIRS[@]} -type f -writable 2>/dev/null | while read binary ; do case "$(file -biz "$binary")" in *compressed-encoding*) # Skip compressed binaries ;; -- 1.6.6.1

4 6