On Thu, Sep 3, 2009 at 23:49, Michael_google gmail_Gersten<[email protected]> 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<[email protected]> wrote: >> #21072: Cannot force a change to +universal >> -----------------------------------------------+---------------------------- >> Reporter: michael-macpo...@… | Owner: >> macports-tick...@… >> Type: defect | Status: closed >> Priority: Normal | Milestone: >> Component: ports | Version: 1.8.0 >> Resolution: invalid | Keywords: >> --enforce-variants >> Port: | >> -----------------------------------------------+---------------------------- >> Changes (by t...@…): >> >> * 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 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
