gio-fam-backend

dougs

dougs

Hello,

I'm having issues with trying to remove the devel/gio-fam-backend port from our servers. Following instructions in the 20130731 entry in /usr/ports/UPDATING which are as follows:
Code: 
  Note that users of pkg packages can just run the pkg delete command after
  their next update.

  # portmaster -r gio-fam-backend
  # pkg_delete gio-fam-backend (for pkgng: pkg delete gio-fam-backend)
  # portmaster -a
After executing each of the three commands, I still show gio-fam-backend as part of the ports as follows:
Code: 
  volans-root# pkg_version -vL=
  gio-fam-backend-2.34.3              !   Comparison failed
  volans-root#
The ports show that devel/glib20 has successfully installed. When I attempted to pkg_delete gio-fam-backend, it stated that the gio-fam-backend does not exist as follows:
Code: 
  volans-root# pkg_delete gio-fam-backend
  pkg_delete: no such package 'gio-fam-backend' installed
  volans-root#
What do I need to do in order to remove the devel/gio-fam-backend from the ports tree?

~Doug
 
Gah, don't do that. pkg_delete(1) needs the full port name or glob match:
# pkg_delete gio-fam-backend-2.34.3
or
# pkg_delete gio-fam-backend-\*

Of course, neither of these will work now that the entry in /var/db/pkg has been deleted.
 
wblock@ said:
Gah, don't do that. pkg_delete(1) needs the full port name or glob match:
# pkg_delete gio-fam-backend-2.34.3
or
# pkg_delete gio-fam-backend-\*

Of course, neither of these will work now that the entry in /var/db/pkg has been deleted.
Click to expand...

Warren-

I didn't delete it- I merely moved it to /var/db/pkg_HOLD. After moving it back to /var/db/pkg, I ran:

# pkg_delete gio-fam-backend-\*

and it did the trick! Thanks!

~Doug
 
:(

Similar problem for me, portmaster -a always wants to reinstall:
Code: 
portmaster -a
===>>> Gathering distinfo list for installed ports

===>>> Starting check of installed ports for available updates

        ===>>> The devel/gio-fam-backend port moved to devel/glib20
        ===>>> Reason: Obsoleted by new functionality in glib20

===>>> Launching child to reinstall gio-fam-backend-2.34.3

===>>> All >> gio-fam-backend-2.34.3 (1/1)

        ===>>> The devel/gio-fam-backend port moved to devel/glib20
        ===>>> Reason: Obsoleted by new functionality in glib20


===>>> Currently installed version: glib-2.36.3
===>>> Port directory: /usr/ports/devel/glib20

===>>> Launching 'make checksum' for devel/glib20 in background
===>>> Gathering dependency list for devel/glib20 from ports
===>>> Initial dependency check complete for devel/glib20

===>>> Returning to update check of installed ports


===>>> All >> (1)

===>>> The following actions will be taken if you choose to proceed:
        Re-install glib-2.36.3

But unfortunately for me:
Code: 
# pkg_delete gio-fam-backend-\*
pkg_delete: no such package 'gio-fam-backend-*' installed
 
How did you know I only read it retrospectively? :)

I guess if I had followed the advice in UPDATING first I couldn't have got into the above situation.

Your blog post actually tackles the reason I had become lax in reading UPDATING (too much stuff not relevant to me), as you show how to limit it to just see info related to currently installed ports, which I guess is what most people are interested in.

So, this enables me to more realistically keep on top of the comments I need to read in UPDATING.

Having said that, have you any idea of a method to get myself out of the above hole retrospectively? Thanks
 
Using a package builder like ports-mgmt/poudriere is now the optimal solution and does not require much work to set up. It also doesn't take much more CPU/memory/disk resources (mostly just some extra disk space to hold the jail) than building everything with for example ports-mgmt/portmaster. The package builder guarantees that dependencies are solved properly and everything that needs to be rebuilt will get rebuilt. See my HOWTO:

PKGNG package repository using ports-mgmt/poudriere. No ZFS required
 
Guess we have different views on the matter but I don't really trust ports-mgmt/portmaster to do a proper job of tracking down all the changed dependencies anymore. It's not developed very actively at the moment and there are many scenarios where it will fail to recompile everything that needs recompiling even if you follow the UPDATING instructions to the letter. Poudriere on the other hand does the job for me much better because it can track not only changed dependencies but also changed options for example. You also get the luxury of not having to worry about leftover files from previous installs messing with your compilations.
 
kpa said:
Guess we have different views on the matter but I don't really trust ports-mgmt/portmaster to do a proper job of tracking down all the changed dependencies anymore. It's not developed very actively at the moment and there are many scenarios where it will fail to recompile everything that needs recompiling even if you follow the UPDATING instructions to the letter. Poudriere on the other hand does the job for me much better because it can track not only changed dependencies but also changed options for example. You also get the luxury of not having to worry about leftover files from previous installs messing with your compilations.
Click to expand...

Sorry for the mess of text to follow, but its last sentence seems to be the main reason for it all. Don't wish to sound complaining, after all this is FreeBSD not linux...

UPDATING >> portmaster here. Really somewhat inconvenienced by features missing in the latter, especially since the impending deprecation of /var/db/pkgfiles means one may not likely easily develop scripts as front ends to ports mgmt tools. And poudriere AFAIK does not have a flowchart (which I am usually fond of, think INFOGRAPHIC ) detailing disk space required? each evironment variable? workflow afterword? before one begins to install it. Eventually I will read guides and the manual, but back in 2005, say, one's upgrade methods and tools were more or less already setup for the end user without local planning, say on a 4-gigabyte pentium three. One could detail it all in a paragraph in an email to someone... I don't see that happening nowadays.
 
Between /usr/ports/UPDATING and portmaster, everything should be covered. In practice, I do occasionally find missed things with pkg_libchk from sysutils/bsdadminscripts. A rebuild of those fixes it, and without setting up a custom build environment like poudriere or tinderbox. IMO, the UPDATING/portmaster/pkg_libchk solution is simpler and the best choice for most users.

@jb_fvwm2, we've talked about your setup before. I remain convinced that most of your difficulties are due to path dependence. The process you've chosen may work for you (although with difficulty), but consider setting up a test system that uses the standard port procedures. It's very likely you'll find the problems are more in perception than anything else. /var/db/pkg is just a database, and so is the new SQLite stuff in pkg. The query methods are different but at least as capable.
 
Last edited by a moderator:
To expound upon my earlier post, I wish that [cmd=] portmaster -USE clang [/cmd], for instance, would negate a gcc set in make.conf ; a portmater -PP -i category/port category/port would not halt upon the first instance of failure in the command parameters; ... and a slew of others.

Presently ignoring the use of SQLite as a package database, until it auto-includes a /var/db/pkg/+CONTENTS. Saving a screenshot of this reply to remind myself to craft one when/if I get around to using pkg. [Lack of time].
.................................................
Not to mention that is consistently fails to build !

===> License BSD accepted by the user
===> Fetching all distfiles required by pkg-1.1.4_8 for building
===> Extracting for pkg-1.1.4_8
===> License BSD accepted by the user
===> Fetching all distfiles required by pkg-1.1.4_8 for building
=> SHA256 Checksum OK for pkg-1.1.4.tar.xz.
===> Patching for pkg-1.1.4_8
===> Applying FreeBSD patches for pkg-1.1.4_8
===> pkg-1.1.4_8 depends on executable: gcc47 - found
===> pkg-1.1.4_8 depends on file: /usr/local/bin/as - found
===> Configuring for pkg-1.1.4_8
===> Building for pkg-1.1.4_8
sed -e 's,%%PKGVERSION%%,1.1.4,' Doxyfile.in > Doxyfile
===> external (all)
===> external/sqlite (all)
Warning: Object directory not changed from original /usr/ports/ports-mgmt/pkg/work/pkg-1.1.4/external/sqlite
gcc47 -O0 -pipe -s -Wl,-rpath=/usr/local/lib/gcc47 -fPIC -DHAVE_READLINE=1 -I/usr/include/edit -DHAVE_POSIX_FALLOCATE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DSQLITE_OMIT_AUTOVACUUM -DSQLITE_OMIT_BLOB_LITERAL -DSQLITE_OMIT_DECLTYPE -DSQLITE_OMIT_EXPLAIN -DSQLITE_OMIT_DEPRECATED -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_OMIT_PROGRESS_CALLBACK -DSQLITE_OMIT_TCL_VARIABLE -DSQLITE_OMIT_UTF16 -DSQLITE_OMIT_CAT -DSQLITE_OMIT_CHECK -DSQLITE_OMIT_AUTOINIT -DSQLITE_OMIT_COMPILEOPTION_DIAGS -DSQLITE_OMIT_INTEGRITY_CHECK -DSQLITE_OMIT_BUILTIN_TEST -DSQLITE_OMIT_SHARED_CACHE -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -DUSE_PREAD -DSQLITE_THREADSAFE=1 -DSQLITE_TEMP_STORE=3 -Dmain=sqlite3_shell -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c sqlite3.c -o sqlite3.o
gcc47 -O0 -pipe -s -Wl,-rpath=/usr/local/lib/gcc47 -fPIC -DHAVE_READLINE=1 -I/usr/include/edit -DHAVE_POSIX_FALLOCATE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DSQLITE_OMIT_AUTOVACUUM -DSQLITE_OMIT_BLOB_LITERAL -DSQLITE_OMIT_DECLTYPE -DSQLITE_OMIT_EXPLAIN -DSQLITE_OMIT_DEPRECATED -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_OMIT_PROGRESS_CALLBACK -DSQLITE_OMIT_TCL_VARIABLE -DSQLITE_OMIT_UTF16 -DSQLITE_OMIT_CAT -DSQLITE_OMIT_CHECK -DSQLITE_OMIT_AUTOINIT -DSQLITE_OMIT_COMPILEOPTION_DIAGS -DSQLITE_OMIT_INTEGRITY_CHECK -DSQLITE_OMIT_BUILTIN_TEST -DSQLITE_OMIT_SHARED_CACHE -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -DUSE_PREAD -DSQLITE_THREADSAFE=1 -DSQLITE_TEMP_STORE=3 -Dmain=sqlite3_shell -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c shell.c -o shell.o
In file included from sqlite3.c:23010:0:
/usr/local/lib/gcc47/gcc/i386-portbld-freebsd9.1/4.7.4/include-fixed/unistd.h:116:0: error: "_POSIX_CPUTIME" redefined [-Werror]
In file included from /usr/local/lib/gcc47/gcc/i386-portbld-freebsd9.1/4.7.4/include-fixed/unistd.h:47:0,
from sqlite3.c:23010:
/usr/include/sys/unistd.h:56:0: note: this is the location of the previous definition
In file included from shell.c:44:0:
/usr/local/lib/gcc47/gcc/i386-portbld-freebsd9.1/4.7.4/include-fixed/unistd.h:116:0: error: "_POSIX_CPUTIME" redefined [-Werror]
In file included from /usr/local/lib/gcc47/gcc/i386-portbld-freebsd9.1/4.7.4/include-fixed/unistd.h:47:0,
from shell.c:44:
/usr/include/sys/unistd.h:56:0: note: this is the location of the previous definition
cc1: all warnings being treated as errors
*** [shell.o] Error code 1
cc1: all warnings being treated as errors
*** [sqlite3.o] Error code 1
2 errors
*** [all] Error code 2
1 error
*** [all] Error code 2
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** [do-build] Error code 1

Stop in /usr/ports/ports-mgmt/pkg.
*** [/usr/ports/ports-mgmt/pkg/work/.build_done.pkg._usr_local] Error code 1

Stop in /usr/ports/ports-mgmt/pkg.
..........................


Howsoever, today I noticed many gmake ports "halt" without any specific error onscreen.... which leads to
Another wish/suggestion
pkg-lsof "These files/libraries, listed in order of size or alphabetically or suffix, were used to compile this port. Files/libraries which duplicate a standard install are asterisked..." Thus one could maybe [if such a tool existed] compare the local build to the maintianers' build, to catch an errant local file that is stalling the usual build [maybe a relic .so in /usr/local/lib/compat.
 
You must log in or register to reply here.
Back
Top