port -u upgrade outdated
Thomas De Contes
d.l.tDeContes at free.fr
Fri Oct 5 10:03:17 PDT 2007
Le 5 oct. 07 à 05:14, Ryan Schmidt a écrit :
> On Oct 4, 2007, at 21:57, Thomas De Contes wrote:
>
>> Le 5 oct. 07 à 00:22, Ryan Schmidt a écrit :
>>
>>> On Oct 4, 2007, at 15:44, Emmanuel Hainry wrote:
>>>
>>>>> port -u upgrade anything
>>>>> is equvalent to
>>>>> port upgrade anything
>>>>> port uninstall inactive
>>>>> am I right ?
>>>
>>> No,
>>
>> ah, well,
>> port -u uninstall anything
>> is equvalent to
>> port uninstall anything
>> ?
>> if not, what is different ?
>
> If you only have one version of foo installed, then "port uninstall
> foo" is the same as "port -u uninstall foo".
>
> If you have several versions of foo instaled, for example foo
> 1.2.1_0 and foo 1.2.1_1 and foo 1.2.3_0, then "port uninstall foo"
> will do nothing and print an error message that it does not know
> which version of foo you would like to uninstall, and "port
> uninstall foo @1.2.1_1" will uninstall only foo 1.2.1_1 and leave
> the other two installed,
> and "port -u uninstall foo @1.2.1_1" will I believe uninstall all
> three foos. I don't feel like testing this right now but you're
> welcome to.
no,
in fact the difference between
port -u uninstall foo @1.2.1_1
and
port uninstall foo @1.2.1_1
is that port -u will try to uninstall all dependencies of foo ! curious
> Also I'm not sure what "port -u uninstall foo" would do -- would it
> error out and make you select which foo, or would it just uninstall
> all 3? I don't know.
it prints an error message
it could be useful, uninstalling the inactive versions of foo, don't
you think ?
it would be in phase with "port -u uninstall" which look at all
installed ports :-)
>>>>> port -nfu upgrade outdated
>>>>> doesn't works because the upgrade is not done in the right
>>>>> order ... :-( !
>>>
>>> I believe that's right. I'm not sure what order the upgrades are
>>> done in, but I'm not convinced it's the right order.
>>
>> as i said, when i tried that i got an error ... so there is sth wrong
>
> It could mean there's a bug in the new version of whatever port was
> being updated. It doesn't necessarily mean it was a dependency
> problem.
you're right, "port upgrade outdated" doesn't works either on this
computer
curious, it worked on an other
>
>>> Consider that apache2 depends on apr and apr-util, and that apr-
>>> util also depends on apr. "port outdated" would print these in
>>> the following order: apache2, apr, apr-util. So if you upgrade
>>> these in alphabetical order, apache2 will be upgraded first, and
>>> it will build against your old version of apr and apr-util. Then
>>> apr will be upgrated, and then apr-util will be upgrated and will
>>> link against the new version of apr. If the changes in apr and
>>> apr-util are minor (binary compatible with the previous release),
>>> this won't be a problem, but if the ABI changed, then apache2
>>> will be broken after apr and apr-util are upgraded. Also, it may
>>> be a problem that apache2 uses apr-util but apache2 and apr-util
>>> have been built against different versions of apr.
>>
>> well, if apr and apr-util are outdated, but not apache2, we need
>> to rebuild apache2 because it depends on ports which are upgrated,
>> is it right ?
>> does "port upgrade outdated" do it ??
>> if yes and no, "port -u upgrade outdated" is right to do not
>> uninstall by default, since it may cause stuff to stop working
>
> If the ABI has not changed in the new version of apr or apr-util,
> then no, apache2 probably does not need to be rebuilt. However, if
> the ABI did change,
(i don't know what is the ABI)
> then yes, anything that depends on apr and apr-util should be
> rebuilt, and no, port upgrade outdated does not do it for you.
> Hence, occasional problems such as the one in the problem hotlist
> after gettext was updated from 0.14.x to 0.15.x:
>
> http://trac.macosforge.org/projects/macports/wiki/
> ProblemHotlist#a2.Aportfailedtobuildupgradeorrunwithamessagereferringt
> olibintl.3.dylib
well, this kind of problem may happens even if the old version of the
port is already installed,
i.e. it may happens even if we do only "port upgrade outdated", not
only if we do sth like "port -nfu upgrade outdated"
is it right ?
>
>> so, it would be good to make an option to port which allow us to
>> force to rebuid *dependents* of ports which are upgrated, but not
>> *dependencies* of them
>> so that, "port -u upgrade outdated" should be able to uninstall
>> without -f , is it right ? :-)
>
> It would be useful not to need to "force" something that is a
> rather regular operation, yes.
if i'm right,
it would be nice to improve macports now, by allowing to uninstall a
port without -f, even if it has dependents, if there is an earlier
version of the same port installed,
since it doesn't change anything for this problem
> I'm not sure of the correct way to implement it. I haven't given it
> much thought.
i hope that some other guys of macports are reading us, and will
think about it :-)
maybe it's needed to create a new mechanism so that "port upgrade
outdated" will know when it needs to rebuild a dependent, without
rebuild them at each time
>
>> ps :
>> "man port" says "outdated: *installed* ports that are out of
>> date ..."
>> but it seems that it is *active* ports, not installed ones
>
> I agree with you:
>
> So either we have a bug in the manpage, or we have a bug in base.
> You may wish to submit a ticket in Trac for this problem.
ok, i'll submit all of that as soon as i have time :-)
--
j'agis contre l'assistanat, je travaille dans une SCOP !
More information about the macports-users
mailing list