/usr/ports & portupgrade when only using packages
Mel
fbsd.questions at rachie.is-a-geek.net
Wed Sep 5 14:17:42 PDT 2007
On Wednesday 05 September 2007 22:09:18 Nikola Lecic wrote:
> Mel,
Nikola,
>
> On Wed, 5 Sep 2007 20:53:24 +0200
> Mel <fbsd.questions at rachie.is-a-geek.net> wrote:
>
> [...]
You cut out some context there, relevant to your response. Namely, the user
wanted to know if you could do without a populated /usr/ports and just use
pkg_add/pkg_delete.
As such, slashing irrelevant answers.
> > You could manage with pkg_add/pkg_delete, but then:
> > 1) *You* have to find out which packages are eligible for upgrading
> > 2) Upgrading a package will mean delete the old version before
> > installing the new one
>
> Deleting the old version before installing the new one (obviously!)
> happens always when you upgrade/downgrade/reinstall something, whatever
> method you choose (compiling through ports or using packages).
It's not so obvious. If you use pkg_add thinking to upgrade package foo, you
will instead get an error indicating that the package with that origin is
already installed.
> If you
> compile through port, a package will be created on your machine after
> compile, so the result should be the same (unless you have custom
> options).
A package is not automatically created (portupgrade -p does this). And no,
packages created with -p (make package target) are not guaranteed to be the
same as packages created with pkg_create -b, which portupgrade uses to repack
dependants (portupgrade -rp). I still am figuring out exactly why this is
(check out PKG_ARGS and ACTUAL_PACKAGE_DEPENDS magic
in /usr/ports/Mk/bsd.port.mk), but I've compared +CONTENTS of installed port
and it's package created by portupgrade on several occasions, and found it to
be quite different, so my slave machines get the wrong dependencies.
Now I just don't use -p on the build machine and run a php script to repack
packages (recursively) after portupgrade -a.
> > (Yes, I realize portupgrade does this)
>
<slash portupgrade advocacy I'm already aware of and using>
> If a machine is slow, it's a good idea to fetch packages first (either
> with '-P -F' or with '-PP -F') and have a look what will be used in a
> real install.
Trust me, I know portupgrade in and out and don't need to be convinced it does
a good job running in source mode.
Here's my list of things it does badly in -PP (binary) mode, please read
carefully:
- takes ages to find out dependencies contained in packages it downloaded,
when the packages are big, because it extracts the entire package. [1]
- downloads dependant packages that it later doesn't install, because the
original package contains that dependency, but the local system contains a
newer version.
- When using portinstall -PP cat/foo it will go to /usr/ports/cat/foo and run
make all-depends-list which recursively lists all dependencies, especially
with Xorg ports, this takes ages before anything happens. It is a needless
step in -PP mode, because it should just download the package archive,
extract it's contents file, and work from there.
[1] This is the first thing I programmed differently:
$ time pkgdeps koffice-1.6.3_2,2.tbz
atk-1.18.0_1 (accessibility/atk)
arts-1.5.7_1,1 (audio/arts)
<list slashed>
real 0m0.166s
user 0m0.094s
sys 0m0.020s
Core func responsible for that:
char *extractPkgContents(const char *path)
{
struct archive *pkg;
struct archive_entry *entry;
char *buff = NULL;
size_t len = 0;
FILE *pkgFile;
pkgFile = fopen(path, "rb");
if( !pkgFile )
return NULL;
pkg = archive_read_new();
archive_read_support_compression_bzip2(pkg);
archive_read_support_format_tar(pkg);
archive_read_open_FILE(pkg, pkgFile);
while(archive_read_next_header(pkg, &entry) == ARCHIVE_OK)
{
if( !strcmp(CONTENTS_FNAME, archive_entry_pathname(entry)))
{
len = archive_entry_size(entry);
buff = (char *)malloc(len+1);
if( !buff )
return NULL;
archive_read_data(pkg, (void *)buff, len);
buff[len] = '\0';
break; /* we got what we want, bail out */
}
archive_read_data_skip(pkg);
}
archive_read_finish(pkg);
fclose(pkgFile);
return buff;
}
--
Mel
More information about the freebsd-questions
mailing list