[MacPorts] #21072: Cannot force a change to +universal
toby at macports.org
Fri Sep 4 03:15:59 PDT 2009
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
>> 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.
More information about the macports-dev