hi
if you install packages in a chroot just as a dependency and remove them
just after the build, then it worth to skip the pre/post_install/remove
scriptlets
http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=pacman;a=plain_commitdi…;
this patch implements this for libalpm & pacman
yes, the patch does not apply cleanly, there is a failed hunk, but
Aurelien said before that's the a big problem so i won't fix it
also probably the the value of PM_TRANS_FLAG_NOSCRIPTLET should be
changed to 0x100
udv / greetings,
VMiklos
--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org
Hello,
I've closed items:
[3] code synchro with pacman 2.9.8
[5a] db_write: database entries cleanup
[11] _alpm prefix to private library functions
On-going items:
[7] (vmiklos)
[8] (aurelien)
the .lastupdate code was moved from the library to the frontend.
FYI, I'm currently working on item [6]
Here is the updated TODO:
[2] possible db corruption because of pmsyncpkg_t struct:
the spkg field is just a pointer to data from the cache, which is likely
to change during sync_commit
[5] database cleanup
b) do not add name and version entries in "desc" file (already available
in the directory name), and also for .PKGINFO file (in makepkg)?
=> on hold for now
[6] more debug messages in libalpm
some parts of the code still remain obscure (file conflicts handling for
instance) even when running pacman with "--debug=-1"
[7] remove exit() calls from libalpm
the library should never call exit() but always return an error code to
the frontend (for instance, drop MALLOC macro)
[8] .lastupdate review
Is the .lastupdate file really needed? Using mtime isn't enough?
[9] review file conflict code
See this thread:
http://www.archlinux.org/pipermail/pacman-dev/2006-February/000202.html
[10] pacman -Sw
Outputs are wrong compared to pacman 2.9
Do not use log callbacks when the -w is used? or filter all outputs in
trans.c depending on the downloadonly flag?
=> it should be done as the last step before a first release to avoid
introducing too much changes to the CVS code at once.
--
Aurelien
hi
what about to the following improvement:
old:
$ sudo pacman -S misc-fonts --ignore corefonts
:: group misc-fonts:
corefonts fontconfig fontforge
:: Install whole content? [Y/n]
:: corefonts-1.3r4-4: local version is up to date. Upgrade anyway? [Y/n]
:: fontforge-20060125-1: local version is up to date. Upgrade anyway? [Y/n]
resolving dependencies... done.
looking for inter-conflicts... done.
Targets: corefonts-1.3r4-4 fontconfig-2.3.93-1 fontforge-20060125-1
Total Package Size: 6.8 MB
Proceed with upgrade? [Y/n] n
new:
$ sudo pacman -S misc-fonts --ignore corefonts
:: group misc-fonts:
corefonts fontconfig fontforge
:: Install whole content? [Y/n]
:: About to install corefonts, but it is in IgnorePkg. Install anyway? [Y/n]
:: corefonts-1.3r4-4: local version is up to date. Upgrade anyway? [Y/n]
:: fontforge-20060125-1: local version is up to date. Upgrade anyway? [Y/n]
resolving dependencies... done.
looking for inter-conflicts... done.
Targets: corefonts-1.3r4-4 fontconfig-2.3.93-1 fontforge-20060125-1
Total Package Size: 6.8 MB
Proceed with upgrade? [Y/n] n
comments?
udv / greetings,
VMiklos
--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org
hi all
just wanted to suggest let's make a list of bugs that blocks us to
release a public rc (and then the first stable) release of pacman3
we have several ideas, for example replacing the ugly chroot system()
call, adding gettext support, etc, but these features were not in
pacman2, and i think they're not "musthave"
so what are the points from TODO that must be solved before a release?
i think the only one is the lack of handling of package conflicts
during packages replacement, and maybe the manpages of public funtions
(via doxygen)
udv / greetings,
VMiklos
--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org