Wonderful packages (size mismatch, cannot continue)

H

hruodr

Code: 
root@fbsd% pkg install emacs25-25.1,3
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 6 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        emacs25: 25.1,3
        ImageMagick: 6.9.6.4_1,1
        fftw3: 3.3.6.p1_1
        liblqr-1: 0.4.2
        libfpx: 1.3.1.4_1
        pkgconf: 1.3.0,1

Number of packages to be installed: 6

The process will require 146 MiB more space.
47 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/6] Fetching emacs25-25.1,3.txz: 100%   39 MiB 657.5kB/s    01:02   
pkg: cached package emacs25-25.1,3: size mismatch, fetching from remote
[2/6] Fetching emacs25-25.1,3.txz: 100%   39 MiB 503.3kB/s    01:21   
pkg: cached package emacs25-25.1,3: size mismatch, cannot continue
 
Thanks. But how I could have guess it?

It was simpler to download Emacs 25.2 and compile it myself.

And now I have sharp fonts (Because of unsharp fonts I deleted Emacs 24 package that is not any more there).

It needs realy time to get a usable system!
 
Why? Downloading from GNU Web-Page and compiling was (in this case) easy and unproblematic.

But now I have a new question.

Packages seems to be continously updated. Can also the ports be updated? Does one get inconsistencies?
 
hruodr said:
Downloading from GNU Web-Page and compiling was (in this case) easy and unproblematic.
Click to expand...
Except when there are exceptions in the Makefile, configuration and software that make such installations not work. Hence the need for FreeBSD ports and packages. They save you the time debugging incompatible issues yourself.

Packages are pre-packed ports. Packages trail ports by hours, days, weeks because someone must compile and upload them.
 
drhowarsdrfine, you wrote a lot, but did not say anything new to me, in particular you did not answer my question.
 
hruodr said:
Why? Downloading from GNU Web-Page and compiling was (in this case) easy and unproblematic.
Click to expand...
Sure, this time perhaps. But the software is now unregistered, so it doesn't show up as installed. Which means there's no version tracking, no specific FreeBSD patches, libraries and executables may have been installed in the wrong place. Updating is going to be difficult since you don't know what else it installed.

hruodr said:
Packages seems to be continously updated.
Click to expand...
The default setting is to use the quarterly branches. These are only updated once every three months or for security issues.

hruodr said:
Can also the ports be updated?
Click to expand...
Handbook: Chapter 4. Installing Applications: Packages and Ports

Does one get inconsistencies?
Click to expand...
You've already created a big inconsistency. You installed something outside of the package/ports system. So there's something installed the system doesn't know about. And this could cause all sorts of interesting conflicts or build issues further along the line.
 
hruodr said:
drhowarsdrfine, you wrote a lot, but did not say anything new to me, in particular you did not answer my question.
Click to expand...
Of course, he did! He clearly explained why you should use ports:
drhowarddrfine said:
Except when there are exceptions in the Makefile, configuration and software that make such installations not work. Hence the need for FreeBSD ports and packages. They save you the time debugging incompatible issues yourself.
Click to expand...
 
SirDice said:
You've already created a big inconsistency. You installed something outside of the package/ports system. So there's something installed the system doesn't know about. And this could cause all sorts of interesting conflicts or build issues further along the line.
Click to expand...

Perhaps the system doesn't know about it, but I. My instalation began with the command:

configure --prefix=/usr/opt/emacs-25.2 --without-all --with-x-toolkit=no

Done as user opt with home directory /usr/opt.

I think there are two views of computers: (1) a programmable machine, (2) an application machine. In the second case the user is an idiot and should not even compile a program, only install aplications. The operating system is then inflated with intransparent management programs, because you cannot expect that idiots edit configuratuion files with an text editor.

Well, but my original question: how to update the port collections? And updating it and compiling from there
would lead to inconsistencies with previos compiled programs?

P.S. drhowarddrfine, thanks for teaching idiots.
 
SirDice said:
You've already created a big inconsistency. You installed something outside of the package/ports system. So there's something installed the system doesn't know about. And this could cause all sorts of interesting conflicts or build issues further along the line.
Click to expand...
I usually install self-compiled software into a subdirectory of the home directory so that it can't clash with any system software, and put the path to that ahead of /usr/local/bin/, etc. in $PATH.
 
Nyanstic, I installed emacs-25.2 in a directory for it (/usr/opt/emacs-25.2). As non root (user is opt). I can unstinstall with rm -r. I can keep it and install other versions of emacs. The same with other programs and libraries.

I have /usr/opt/bin in $PATH of the working user, hence I did inside it ln -s /usr/opt/emacs-25.2/bin/emacs-25.2 emacs. I can change the link if I install other version, I can delete it if I install a package emacsXYZ.

I tried a time ago to compile the port brlcad that was not anymore in the packages. It was impossible, because there was a conflict with a version of python that was automatically installed with pkg install after installing other package, brlcad depended on other version of python.

As you see, the updating of packages and ports do generate inconsistencies. It makes FreeBSD unreliable for people that needs some programs, specially if they are not able to compile them.

As I see, the ability to update ports in a release, the updating of packages, is something new.
 
hruodr said:
tried a time ago to compile the port brlcad that was not anymore in the packages. It was impossible, because there was a conflict with a version of python that was automatically installed with pkg install after installing other package, brlcad depended on other version of python.

As you see, the updating of packages and ports do generate inconsistencies.
Click to expand...
It's not the ports/packages that created the inconsistencies. If you set DEFAULT_VERSIONS correctly everything will be built against the same Python version.
 
Code: 
% cd /usr/ports/devel/tnt/
% make
===>  Found saved configuration for tnt-1.2.6
===>   tnt-1.2.6 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by tnt-1.2.6 for building
===>  Extracting for tnt-1.2.6
=> SHA256 Checksum OK for tnt/tnt_126.zip.
=> SHA256 Checksum OK for tnt/tnt120doc.zip.
===>   tnt-1.2.6 depends on file: /usr/local/bin/unzip - not found
===>   tnt-1.2.6 depends on file: /usr/local/bin/unzip - not found
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/devel/tnt
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/tnt

Code: 
% which unzip
/usr/bin/unzip
 
What is the difference?

Then I wonder, why it did not fetch and install it.

I was thinking of doing a link in /usr/local/bin.
 
hruodr said:
What is the difference?
Click to expand...
Different implementations and probably different behavior.

Then I wonder, why it did not fetch and install it.
Click to expand...
Now, that's a good question. It should be pulled in automatically. Is there anything in /etc/make.conf?

hruodr said:
I was thinking of doing a link in /usr/local/bin.
Click to expand...
Don't. There's probably a good reason it needs archivers/unzip or else it would simply have used /usr/bin/unzip. (creating links like that are a sure way of getting inconsistencies. Don't do it. Don't even consider it as a 'solution').
 
I think, I compiled it before, something changed in the meantime. And it is the pots collection of the distribution. I did not update it.


Code: 
% cd /usr/ports/devel/bison
% make clean
===>  Cleaning for texinfo-6.1.20160425
===>  Cleaning for bison-2.7.1,1
% make
===>  Found saved configuration for bison-2.7.1,1
===>   bison-2.7.1,1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by bison-2.7.1,1 for building
===>  Extracting for bison-2.7.1,1
=> SHA256 Checksum OK for bison-2.7.1.tar.xz.
===>  Patching for bison-2.7.1,1
===>   bison-2.7.1,1 depends on package: m4>=1.4.16,1 - found
===>   bison-2.7.1,1 depends on executable: makeinfo - not found
===>  Found saved configuration for texinfo-6.1.20160425
===>   texinfo-6.1.20160425 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by texinfo-6.1.20160425 for building
===>  Extracting for texinfo-6.1.20160425
=> SHA256 Checksum OK for texinfo/6.1.20160425/texinfo-6.1.tar.xz.
=> SHA256 Checksum OK for texinfo/6.1.20160425/htmlxref.cnf.
=> SHA256 Checksum OK for texinfo/6.1.20160425/texinfo.tex.
=> SHA256 Checksum OK for texinfo/6.1.20160425/texi2dvi.
===>  Patching for texinfo-6.1.20160425
/bin/chmod 755 /usr/ports/print/texinfo/work/texinfo-6.1/build-aux/install-sh
cp -f /usr/ports/distfiles/texinfo/6.1.20160425/texinfo.tex /usr/ports/print/texinfo/work/texinfo-6.1/doc/
install  -m 555 /usr/ports/distfiles/texinfo/6.1.20160425/texi2dvi /usr/ports/print/texinfo/work/texinfo-6.1/util/
/usr/bin/sed -i.bak '/rm -f ..DESTDIR/s:$: $(DESTDIR)$(xsdir)/XSParagraph.*:'  /usr/ports/print/texinfo/work/texinfo-6.1/tp/Texinfo/Convert/XSParagraph/Makefile.in
===>   texinfo-6.1.20160425 depends on executable: help2man - not found
===>   texinfo-6.1.20160425 depends on executable: help2man - not found
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/print/texinfo
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/print/texinfo
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/devel/bison
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/bison
 
Well, making make clean inside of /usr/port/misc/help2man solves the problem. But no idea why this was a problem.

help2man was compiled automatically when compiling other port. Should not make clean also clean dependencies?
 
And below the problem with make in /usr/ports/cad/brlcad.

What do you think I should do with DEFAULT_VERSIONS?

----

Code: 
===>   py27-setuptools27-20.0 depends on file: /usr/local/bin/python2.7 - found
===>  Checking if py27-setuptools27 already installed
===>   Registering installation for py27-setuptools27-20.0 as automatic
Installing py27-setuptools27-20.0...
pkg-static: py27-setuptools27-20.0 conflicts with py27-setuptools-32.1.0_1 (installs files into the same place).  Problematic file: /usr/local/lib/python2.7/site-packages/easy-install.pth.dist
*** Error code 70

Stop.
make[6]: stopped in /usr/ports/devel/py-setuptools27
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/devel/py-Jinja2
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/devel/py-Jinja2
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/textproc/py-sphinx
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/devel/cmake
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/devel/cmake
*** Error code 1

Stop.
make: stopped in /usr/ports/cad/brlcad
 
hruodr said:
Code: 
Installing py27-setuptools27-20.0...
pkg-static: py27-setuptools27-20.0 conflicts with py27-setuptools-32.1.0_1 (installs files into the same place).  Problematic file: /usr/local/lib/python2.7/site-packages/easy-install.pth.dist
*** Error code 70
Click to expand...
Please read /usr/ports/UPDATING:
Code: 
20170316:
  AFFECTS: users of python setuptools
  AUTHOR: antoine@FreeBSD.org

  The python setuptools ports have been renamed to better match other python ports.
  Ports users need to rename them so that portupgrade and portmaster do not
  get confused.  For example:

    pkg set -n py27-setuptools27:py27-setuptools
    pkg set -o devel/py-setuptools27:devel/py27-setuptools
  or
    pkg set -n py35-setuptools35:py35-setuptools
    pkg set -o devel/py-setuptools35:devel/py35-setuptools
 
hruodr said:
Should not make clean also clean dependencies?
Click to expand...
It should, yes. But you may get some left-overs (previously failed builds for example). A quick way to "make clean" everything: rm -rf /usr/ports/*/*/work. It does the same as make -C /usr/ports clean but is a lot faster.
 
Well, my /usr/ports/UPDATING is from 2016-09-28 and does not contain that (from 2017-03-16).

Perhaps the conflict is with something installed by pkg install.

But cad/brlcad is older (and not in pkg).

Will cad/brlcad disappear if I update the port collections?
 
You must log in or register to reply here.
Back
Top