[MacPorts] #21072: Cannot force a change to +universal

[Toby Peterson]

On Thu, Sep 3, 2009 at 23:49, Michael_google
gmail_Gersten<keybounce at gmail.com> wrote:
> I cannot submit a change (including "re-open") on the tracker. I am
> responding here instead.
>
> On Thu, Sep 3, 2009 at 8:10 PM, MacPorts<noreply at macports.org> wrote:
>> #21072: Cannot force a change to +universal
>> -----------------------------------------------+----------------------------
>>  Reporter:  michael-macports@…                |       Owner:  macports-tickets@…
>>      Type:  defect                            |      Status:  closed
>>  Priority:  Normal                            |   Milestone:
>>  Component:  ports                             |     Version:  1.8.0
>> Resolution:  invalid                           |    Keywords:  --enforce-variants
>>      Port:                                    |
>> -----------------------------------------------+----------------------------
>> Changes (by toby@…):
>>
>>  * status:  new => closed
>>  * resolution:  => invalid
>>
>>
>> Comment:
>>
>>  You obviously don't need --enforce-variants when installing, since there's
>>  nothing to enforce. The rest of your report is #126.
>>
>> --
>> Ticket URL: <http://trac.macports.org/ticket/21072#comment:2>
>> MacPorts <http://www.macports.org/>
>> Ports system for Mac OS
>
> This isn't #126, and there is a need at install time.
>
> If I am installing X, and specifying +universal, then any uninstalled
> dependency of X also gets +universal. But existing dependencies that
> do not have +universal are not upgraded, and cannot be forced to
> upgrade. There is no current option to "Enforce the variants that I'm
> installing with on the child dependents".
>
> Equally, there is no way I can find to determine the complete list of
> currently installed dependents and the list of not-yet-installed
> dependents. If there was, I could just get the installed dependents,
> and do an upgrade --enforce-variants on them.
>
> But that is exactly what I want -- when installing X +universal, any
> not-yet-installed dependents get installed with +universal, and any
> already-installed dependents get upgrade --enforce-variants.
>
> This is something that is "trivial" (for some value of trivial) for
> the code to do as it does the install and dependency check, and very,
> very time consuming/painful for humans to do.
>
> Nor is it easy to uninstall things. As in, uninstall all the
> dependencies to re-install them. All it takes is one other program
> using them (very very common on some low-level libraries).
>
> #126 -- 7 years??? -- would address the issue of "If I'm installed
> with +darwin9, then I need X installed with +darwin". It does nothing
> to address the "I'm going in as +universal, now that one needs to be
> changed to +universal. I'm going in as +darwin, now that one needs to
> be changed to +darwin".
>
> In a very serious vein, it is (more than) conceivable that you may
> need a given library in two different variants for two different
> programs; the library in question should appears twice in the file
> system, in two different locations, with different names. That isn't a
> MacPort issue -- that's a general flawed unix file system layout issue
> -- /usr/lib/library.a should be /usr/lib/<flavor>/library.a, and
> searching the libraries should be sufficiently smarter :-).
>
> Put it this way: If you say that there is no need for this, then
> please tell me how I can easily get my relevant installed ports to be
> upgraded to +universal? Please do not say "sudo port upgrade
> --enforce-variant +universal installed" -- that will upgrade
> everything under the sun to universal, even the things that are
> perfectly fine as PPC only.

You happen to be running into a variety of related issues. A short
(but incomplete) list:

(1) ports cannot specify the archs they actually support
(2) we do not record the built archs in the registry
(3) +universal shouldn't be a variant
(4) +universal doesn't necessarily mean the same thing in all
situations (due to a number of broken ports, as well as possible
configuration changes - see #2)

And so on... basically, what you're asking for requires some pretty
significant infrastructure overhauls - realistically, it's something
that won't happen until we manage to gather the willpower required to
almost entirely rewrite MacPorts.

>From your point of view, I can see why you might think these changes
are easy (NOT trivial, look it up), but you'd be wrong.

- Toby