port 1.300 builds all dependencies regardless of state

[yaseppochi (Stephen J. Turnbull)]

using port -u -f all dependencies get rebuilt unconditionally. this gives absurdities like

Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating readline 5.0.005_0
--->  Uninstalling readline 5.0.005_0
--->  Packaging tgz archive for readline 5.0.005_0
--->  Installing readline 5.0.005_0
--->  Activating readline 5.0.005_0

At least it finds the existing distribution tarballs.

This has been observed just now for sqlite (which didn't need an upgrade but got rebuilt, as well as readline the dependency---the missing "3" was a typo) and sqlite3 (which did need an upgrade), and for several GNOME packages (all libraries) a few days ago.

"port upgrade graphviz" just now only rebuilt graphviz (thank heavens, since it depends on X).

port's dependency algorithms seem really fragile and often unintuitive.

[olegb@…]

Its not quite clean to me what you are trying to do. If you are using

port -dfu upgrade all

you will find out that -f has changed meaning in HEAD. It now rebuilds so this is expected behaviour.

[olegb@…]

closing bug:

this is expected behaviour (documented under upgrade port(1))

[yaseppochi (Stephen J. Turnbull)]

(In reply to comment #1)

Its not quite clean to me what you are trying to do. If you are using

port -dfu upgrade all

you will find out that -f has changed meaning in HEAD. It now rebuilds so this is expected behaviour.

I meant: "when using 'port -u -f upgrade', all dependencies get rebuilt", not "when using 'port -u -f upgrade all'".

In the example, I typed

port -u -f upgrade sqlite

and sqlite (which was not out of date) got rebuilt. This is reasonable in view of the -f, although it's unfortunate because -f also means "force-uninstall inactive versions". What I consider unreasonable is that readline also got rebuilt.

Furthermore, having completed upgrades of both sqlite and sqlite3, if I now type

port -u -f upgrade sqlite sqlite3

readline gets rebuilt *twice*. I haven't been able to find a more complex example that doesn't just die in the middle, but that's another bug report.

[olegb@…]

(In reply to comment #3)

(In reply to comment #1)

Its not quite clean to me what you are trying to do. If you are using

port -dfu upgrade all

you will find out that -f has changed meaning in HEAD. It now rebuilds so this is expected behaviour.

I meant: "when using 'port -u -f upgrade', all dependencies get rebuilt", not "when using 'port -u -f upgrade all'".

In the example, I typed

port -u -f upgrade sqlite

and sqlite (which was not out of date) got rebuilt. This is reasonable in view of the -f, although it's unfortunate because -f also means "force-uninstall inactive versions". What I consider unreasonable is that readline also got rebuilt.

-f is force; though it is unfortunate that it is used in many contexts, it is the expected behaviour in HEAD that to rebuild you:

port -df upgrade portfoo (this will rebuild portfoo)

to uninstall un-actived ports do

port -duf uninstall

Again - this is not a bug, this is expected behavior and documented in port(1).

[yaseppochi (Stephen J. Turnbull)]

At least fix the damn docs.

[olegb@…]

Stephen,

As I have explained - the man page allready meantions this. port(1):

"

To force an upgrade (rebuild) use:

port -f upgrade vim

To upgrade portname wihtout following its dependencies, use -n. For example:

port -n upgrade ethereal

"

And, you are right - this be haviour is new to HEAD. *But* it is expected, and it is documented in the port-manpage.

If you dont agree with this policy - i can see many reason why one wouldnt - please submit a patch and label is RFE. The same goes if you do not like the working of the man-page.

Now, I have explained why this isnt a bug - please respect this - because I am waisting no more time opening/closing this.

[yaseppochi (Stephen J. Turnbull)]

(In reply to comment #6)

Stephen,

As I have explained - the man page allready meantions this. port(1):

Please reread what I wrote AND the man page that you quote; the man page does not mention the behavior I consider unintuitive. I DO expect "port -f upgrade FOO" to rebuild FOO; I DO NOT expect it to rebuild BAR, which I didn't mention, and which there is no reason for me to know is a dependency.

please submit a patch and label is RFE. The same goes if you do not like the working of the man-page.

Hey, if you don't feel like doing the work, just say so. But I'm not the right person to be writing a patch to either code or docs. I don't like the current behavior, I don't understand why you think it's appropriate, so I'm obviously the WRONG person to mess with the docs. I've read some of the Tcl in port; again, I don't understand or like what it's doing, do not know what it should do, only what it should stop doing (but you say that behavior is intentional, so writing a patch is a waste of time, no?), and do not have time to learn a new language.

Here's what the man page needs:

Specifically, "-u" is documented to be useful with "upgrade". This non-feature should be left undocumented since it is deprecated, or explicitly deprecated. The documentation for "upgrade" doesn't mention that "-f" applies to all prerequisites, and it should.

Also, port itself should recommend "[-f] uninstall @VERSION" instead of "-f -u upgrade" when "-u upgrade" is unable to uninstall.

By the way, because of the unreliability of several of the ports that I use, I do NOT want to use "port -f -u uninstall", which would trash known working versions.

I'll leave the bug closed, since you clearly intend to ignore the problem, but I did want to document what needs to be done.

[olegb@…]

(In reply to comment #7)

Here's what the man page needs:

Specifically, "-u" is documented to be useful with "upgrade". This non-feature should be left undocumented since it is deprecated, or explicitly deprecated. The documentation for "upgrade" doesn't mention that "-f" applies to all prerequisites, and it should.

The -u is not meantion with upgrade in the HEAD port(1) manpage.

I have clerified (in port.1) that upgrade works on deps too, and to change that behaviour you must use -R or -n.

Also, port itself should recommend "[-f] uninstall @VERSION" instead of "-f -u upgrade" when "-u upgrade" is unable to uninstall.

port.1 documents port -u uninstall, why isnt that enough ? And why is this unreliable ?

[yaseppochi (Stephen J. Turnbull)]

(In reply to comment #8)

The -u is not meantion with upgrade in the HEAD port(1) manpage.

No, but "upgrade" is mentioned in the documentation of "-u".

I have clerified (in port.1) that upgrade works on deps too, and to change that behaviour you must use -R or -n.

You mean this?

| .Ss upgrade | The upgrade target works on a port and its dependencies. If you | want to change this behaviour, look at the switches for n (no | dependencies) and R (dependents) below.

*sigh* That upgrade (and install) work recursively on trees of dependencies is desirable and expected---this is the whole point of a dependency manager. What I didn't expect is that *options* (especially -f) would apply recursively, so that state of all prerequisites would be completely ignored. I suppose that it is very rare that users actually want to rebuild prerequisites that are up-to-date; rebuilding the dependent package is normally enough to ensure consistency. Anyway, this is true of me; as I describe below, the behavior of forcing an uninstall of an old version without forcing rebuilds of up-to-date prequisites is extremely useful to me.

IMO, that should read

.Ss upgrade will rebuild an outdated package and any outdated prerequisites. "Outdated" means that the Portfile is more recent than the status file. With -n, prerequisite packages are not rebuilt. With -R, packages that depend on the specified package will be rebuilt instead of the prequisites. With -f, the statuses of the package and its prequisites are ignored, and the package and all prerequisites are unconditionally rebuilt unless -n or -R is specified.

Also, port itself should recommend "[-f] uninstall @VERSION" instead of "-f -u upgrade" when "-u upgrade" is unable to uninstall.

port.1 documents port -u uninstall, why isnt that enough ?

Because if the program is nice enough to tell me that I can use "port -f -u upgrade" to get the behavior I probably want, I'm not going to assume that it's lying, and go read the man page. In fact, normally man pages are less up to date than internal error messages and warnings.

And why is this unreliable ?

Recent zsh and GNOME port upgrades have omitted necessary files from the install target, producing apparently successful installs that don't work. GNOME as a whole is a mess; backing up a port to a configuration that is known to work is something I have to do several times a year. So for ports that I actually use, I'm in the habit of keeping a known good version around. But there are lots of dependencies that (as far as I know) I never actually use; I'm willing to take the risk of immediately uninstalling them as long as they build successfully, which is exactly what "port -u -f upgrade FOO" used to do for FOO and all of its prerequisites.

But if I use port -fu uninstall, I will lose all the working ports. This means that I have to trace the dependencies in reverse (otherwise I'll just get the same non-working ports rebuilt by port), and build all the prerequisities in working versions---which must be specified manually. This typically means the dependents must be reverted, too, especially in GNOME which cares very little for backward compatibility---for the last year I have pretty much continuously had several GNOME ports in outdated status because the required versions of their prerequisites couldn't be built.

Therefore it was extremely convenient to be able to do "port -fu upgrade"; I didn't need to know what the old version of a prequisite was or even if there were any outdated prerequisites.

[jmpp@…]

This actually seems to me like a duplicate of #10827, even though it was closed as "wontfix", don't know why.