- Pacman-dev - lists.archlinux.org

[pacman-dev] Backend DB [was: Hypotetic pacman's db structure]
by Aaron Griffin 13 Nov '07

13 Nov '07

On Nov 9, 2007 3:22 PM, Miklos Vajna <vmiklos(a)frugalware.org> wrote: > On Fri, Nov 09, 2007 at 05:26:01PM +0100, JJDaNiMoTh <jjdanimoth(a)gmail.com> wrote: > > I'm writing an example databe structure for pacman db ( may be useful > > when someone decide to use SQLite as backend, and not simple text > > file). [1] > > last year i writed such a structure, but it was much more complex: > > http://git.frugalware.org/gitweb/gitweb.cgi?p=vmexam.git;a=blob;f=sql/pacma… > > and to be honest i must say i agree with Aaron about using an sql-based > db for such a lowlevel purpose (pkgdb) would be something like using > curl in libpacman Hah, this is the second time you agreed with me! The sky is falling! To probe your thoughts a bit further, if the world were ideal, what kind of backend would YOU go for?

6 12

[pacman-dev] Misleading pacman man page
by Aaron Griffin 13 Nov '07

13 Nov '07

This is a man page issue that's actually got me a few times, and seems to confuse users as well. This is the pacman man page. On Nov 12, 2007 5:34 PM, Goulven Guillard <lecotegougdelaforce(a)free.fr> wrote: > Aaron Griffin a écrit : > > On Nov 12, 2007 5:21 PM, Goulven Guillard <lecotegougdelaforce(a)free.fr> wrote: > >> Aaron Griffin a écrit : > >>> For both of the bugs you posted, pacman -Rd is the solution > >> Oh, ok. Sorry, the comment was so tiny that I didn't see it. :-) > >> > >> And thanks for the tip, it seems like I misread pacman's manpage. > > > > It's in the OPTIONS section above all the other ones - it's a little > > misleading, but that section contains the common options for all > > commands. > > Yes, I agree it's misleading. But anyway I have no excuse, I have read > all the manpage... I must be tired. Basically, he didn't know about -Rd because it is not documented in the "REMOVE OPTIONS" section, but above it, and that is not really referenced anywhere. I know I've done a double take once or twice. Options: * Point out the OPTIONS section better - perhaps adding a little "See Also" at the top of each specific options section? * Remove the OPTIONS section and duplicate it in each sub section * Do nothing What do you all think?

2 1

[pacman-dev] [PATCH] repo-add: Ensure only adding package's deltas.
by Nathan Jones 12 Nov '07

12 Nov '07

repo-add was adding the delta files of any package that started with the same package name plus a hyphen. In this example, deltatest-libs delta files were added to the deltatest package: $ repo-add deltatest.db.tar.gz deltatest-1.0.2-1-i686.pkg.tar.gz ==> Extracting database to a temporary location... ==> Adding package 'deltatest-1.0.2-1-i686.pkg.tar.gz' -> Removing existing package 'deltatest-1.0.2-1'... -> Creating 'desc' db entry... -> Computing md5 checksums... -> Creating 'depends' db entry... -> Creating 'deltas' db entry... -> Added delta 'deltatest-1.0.2rc3-1_to_1.0.2-1-i686.delta' -> Added delta 'deltatest-libs-1.0.0-1_to_1.0.1-1-i686.delta' ==> Creating updated database file /tmp/deltatest.db.tar.gz Signed-off-by: Nathan Jones <nathanj(a)insightbb.com> --- scripts/repo-add.sh.in | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in index 4dfedbe..adcefc1 100644 --- a/scripts/repo-add.sh.in +++ b/scripts/repo-add.sh.in @@ -218,7 +218,13 @@ db_write_entry() # create deltas entry if there are delta files for delta in $startdir/$pkgname-*-*_to_*-*-$arch.delta; do - if [ -f "$delta" ]; then + # This for loop also pulls in all files that start with the current package + # name and are followed by a -whatever. For instance, running this loop for + # gcc would also grab gcc-libs. To guard against this, compare the package + # name of the delta to the current package name. + local filename=$(basename "$delta") + local dpkgname="$(echo "$filename" | sed -e 's/$.*$-.*-.*_to_.*-.*-.*.delta/\1/')" + if [ "$pkgname" = "$dpkgname" -a -f "$delta" ]; then # create deltas file if it does not already exist if [ ! -f "deltas" ]; then msg2 "$(gettext "Creating 'deltas' db entry...")" -- 1.5.3.5

1 0

[pacman-dev] [PATCH] Add pactest for IgnoreGroup.
by Nathan Jones 12 Nov '07

12 Nov '07

Also tell pactest to reset IgnoreGroup like it does for IgnorePkg. Signed-off-by: Nathan Jones <nathanj(a)insightbb.com> --- pactest/pmtest.py | 1 + pactest/tests/sync138.py | 22 ++++++++++++++++++++++ 2 files changed, 23 insertions(+), 0 deletions(-) create mode 100644 pactest/tests/sync138.py diff --git a/pactest/pmtest.py b/pactest/pmtest.py index 00dd3cb..e0b3fd4 100755 --- a/pactest/pmtest.py +++ b/pactest/pmtest.py @@ -84,6 +84,7 @@ class pmtest: self.option = { "noupgrade": [], "ignorepkg": [], + "ignoregroup": [], "noextract": [] } diff --git a/pactest/tests/sync138.py b/pactest/tests/sync138.py new file mode 100644 index 0000000..410c7f0 --- /dev/null +++ b/pactest/tests/sync138.py @@ -0,0 +1,22 @@ +self.description = "Sysupgrade of packages in 'IgnoreGroup'" + +sp1 = pmpkg("pkg1", "1.0-2") +sp2 = pmpkg("pkg2", "1.0-2") +sp2.groups = ["grp"] + +for p in sp1, sp2: + self.addpkg2db("sync", p) + +lp1 = pmpkg("pkg1") +lp2 = pmpkg("pkg2") + +for p in lp1, lp2: + self.addpkg2db("local", p) + +self.option["ignoregroup"] = ["grp"] + +self.args = "-Su" + +self.addrule("PACMAN_RETCODE=0") +self.addrule("PKG_VERSION=pkg1|1.0-2") +self.addrule("!PKG_MODIFIED=pkg2") -- 1.5.3.5

1 0

[pacman-dev] [PATCH] makepkg: remove .pacsave files when uninstalling dependencies
by Roman Kyrylych 12 Nov '07

12 Nov '07

Hi! This is a small patch that fixes this: ==> Compressing package... ==> Removing installed dependencies... ERROR: ld.so: object 'libfakeroot.so' from LD_PRELOAD cannot be preloaded: ignored. checking dependencies... done. Targets: at Do you want to remove these packages? [Y/n] warning: /etc/at.deny saved as /etc/at.deny.pacsave (1/1) removing at [#####################] 100% ==> Finished making: gnome-schedule (Sun Nov 11 16:22:29 EET 2007) -- Roman Kyrylych (Роман Кирилич)

3 3

[pacman-dev] add043.py: alpm_depcmp and provisions
by Nagy Gabor 12 Nov '07

12 Nov '07

Hi! Give a look at the following pactest: ----add043.py---- self.description = "provision>=1.0-2 needed" p1 = pmpkg("pkg1", "1.0-2") p1.depends = ["provision>=1.0-2"] self.addpkg(p1) p2 = pmpkg("pkg2", "1.0-2") p2.provides = ["provision"] self.addpkg2db("local", p2) self.args = "-A %s" % p1.filename() self.addrule("PACMAN_RETCODE=1") self.addrule("!PKG_EXIST=pkg1") self.addrule("PKG_EXIST=pkg2") ----------------- This currently fails. IMHO this is a bug: alpm_depcmp uses the package version in the "provision case" too (so if you change p1.depends to "provision<=1.0-1", then the pactest will pass.) This is a good time to ask you about versioned provisions again (before fix): Personally, I like the idea; and the implementation needs ~0 effort and would cause ~0 slowdown; and would be 100% compatible with "no-version" provisions. I don't know if package maintainers need this feature or not (someone could ask them on arch-* ML <- I'm not a subscriber there), but this is just an extra feature, they needn't use it. Bye, ngaba

3 2

[pacman-dev] lstat issue / fileconflict001 pactest
by Xavier 12 Nov '07

12 Nov '07

Following the discussion started in the comments of bug 7484, because I think it's more appropriate : http://bugs.archlinux.org/task/7484#comment20837 I recently discovered that a trailing / is very important when using lstat, for directory symlinks. In the following situation : symdir -> realdir/ lstat(symdir) stats the link itself, but lstat(symdir/) stats realdir. So lstat(symdir/) seems equivalent to stat(symdir). The archive extraction code in add.c that Dan rewrote didn't take this into consideration, so he added a new _alpm_lstat that removes the trailing / when there is one : http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=b55abdce7aebb142… A little typo in _alpm_lstat (path instead of newpath) made this change not active yet. As Dan noticed, fixing this makes fileconflict001 pass. The only purpose of this mail is explaining why. So in this pactest, we have the following situation : dir/realdir/ dir/symdir -> realdir Then pkg1 installs dir/realdir/file , and pkg2 installs dir/symdir/file . Since in this case, symdir points to realdir, pkg1 and pkg2 have a fileconflict on "file". But if fileconflict001 pass after the bugfix mentioned above, it's not because pacman detects there is a package<->package conflict between dir/realdir/file and dir/symdir/file. Instead, it detects a filesystem <-> package conflict between dir/symdir/ from pkg2 (which is a real directory there), and the dir/symdir symlink on the filesystem. So that's plain wrong. The fileconflict code currently does a lstat(dir/symdir/), which doesn't stat the symdir symlink, but the real directory realdir. So it treated dir/symdir/ as a directory, and ignored it : 336 /* stat the file - if it exists, do some checks / 337 if(_alpm_lstat(path, &buf) != 0) { 338 continue; 339 } 340 if(S_ISDIR(buf.st_mode)) { 341 _alpm_log(PM_LOG_DEBUG, "%s is a directory, not a conflict\n", path); Now, with the new behavior of _alpm_lstat, the code does a lstat(dir/symdir), which stats the symlink. And the following code will treat this as a conflict. The case of fileconflict001 is probably another situation easier to detect during the transaction (coupled with a rollback system), rather than beforehand. Otherwise, maybe the file conflict code should keep using the normal lstat, instead of _alpm_lstat which removes the trailing /.

4 9

[pacman-dev] Generate doxygen man pages on "make dist"
by Aaron Griffin 12 Nov '07

12 Nov '07

Would anyone have a problem with generating doxygen man pages on the "make dist" target? The reason I ask, is that having a doxygen makedepend is breaking our little core/extra repo separation, and this is the cleanest fix. It also cleans up building pacman. If you ask me, I don't see a problem with pre-generating them Opinions?

2 2

[pacman-dev] TotalDownload option.
by Nathan Jones 12 Nov '07

12 Nov '07

Sample output: $ sudo pacman -S gcc gcc-fortran gcc-libs resolving dependencies... done. looking for inter-conflicts... done. Targets: gcc-libs-4.2.2-2 [1.06 MB] gcc-4.2.2-3 [8.92 MB] gcc-fortran-4.2.2-1 [2.91 MB] Total Package Size: 12.89 MB Total Download Size: 12.89 MB Proceed with installation? [Y/n] :: Retrieving packages from core... gcc-libs-4.2.2-2-i686 1081.1K 503.8K/s 00:00:02 [#--------------------] 8% gcc-4.2.2-3-i686 10.0M 302.1K/s 00:00:34 [################-----] 77% :: Retrieving packages from extra... gcc-fortran-4.2.2-1-... 12.9M 338.0K/s 00:00:39 [#####################] 100% checking package integrity... done. (3/3) checking for file conflicts [#####################] 100% (1/3) upgrading gcc-libs [#####################] 100% (2/3) upgrading gcc [#####################] 100% (3/3) upgrading gcc-fortran [#####################] 100%

8 20

[pacman-dev] documenting the base-devel split
by Jonathan 12 Nov '07

12 Nov '07

I haven't been able to find any arch documentation (besides the mailing lists) on the splitting of base into base and base-devel groups. The main need is for people to understand the need to install the base-devel group before building packages. the makepkg man page seems like a good place for this. Jonathan 'wide-eye'

7 13