[MacPorts] #34482: iso-codes @3.34_0 Invalid entry was passed
MacPorts
noreply at macports.org
Fri May 18 06:21:11 PDT 2012
#34482: iso-codes @3.34_0 Invalid entry was passed
------------------------------------+---------------------------------------
Reporter: jasperfrumau@… | Owner: macports-tickets@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: base | Version: 2.1.0
Keywords: | Port:
------------------------------------+---------------------------------------
Comment(by cal@…):
The query that selects the dependents of a given port from the database
is:
{{{
sqlite> SELECT dependencies.id FROM ports port INNER JOIN dependencies
USING(name) INNER JOIN ports dependent USING (id) WHERE port.id=2220;
1407
1664
2344
}}}
1664 and 2344 are existing IDs in your `ports` table, however 1407 is not.
Your registry has a couple of other dependency relations pointing to a
non-existing port:
{{{
sqlite> SELECT * FROM dependencies WHERE id = 1407;
1407|gconf|
1407|iso-codes|
1407|enchant|
1407|xorg-libsm|
1407|py27-pygtksourceview|
sqlite> SELECT id,name,version FROM ports WHERE id = 1407;
sqlite>
}}}
This entry 1407 is the only entry referenced from the dependencies table
missing in the ports table:
{{{
sqlite> SELECT dependencies.id,dependencies.name FROM dependencies WHERE
dependencies.id NOT IN (SELECT DISTINCT id FROM ports);
1407|gconf
1407|iso-codes
1407|enchant
1407|xorg-libsm
1407|py27-pygtksourceview
}}}
So knowing this missing port 1407 must be a dependency of `gconf`, `iso-
codes`, `enchant`, `xorg-libsm` and `py27-pygtksourceview` we can just
create the intersection of the dependencies of those ports, leaving us
with `pkgconfig` as only common dependency. You do have `pkgconfig`
installed in version `0.26`, however with a different ID:
{{{
sqlite> SELECT id,name,version FROM ports WHERE name LIKE 'pkgconfig';
2323|pkgconfig|0.26
}}}
So, to fix your problem, change all occurrences of 1407 in the
`dependencies` table to 2323:
{{{
sqlite> UPDATE dependencies SET id = 2323 WHERE id = 1407;
}}}
This should fix your problem and allow you using `port(1)` again.
The more interesting question from a developer point of view is how that
problem came into existence and how it could have been prevented. Changing
the query that fetches dependents from
{{{
sqlite> SELECT dependencies.id FROM ports port INNER JOIN dependencies
USING(name) INNER JOIN ports dependent USING (id) WHERE port.id=2220;
}}}
to
{{{
sqlite> SELECT dependencies.id FROM ports port INNER JOIN dependencies
USING(name) INNER JOIN ports dependent ON dependent.id = dependencies.id
WHERE port.id=2220;
}}}
doesn't return the broken rows; but is this really what we want? We would
exchange aborting using the correct error message (there is no port with
an ID of 1407 after all, so an invalid entry _was_ passed) with ignoring
broken entries in the dependencies table and uninstalling anyway.
We should rather aim to find the location (if any) where a port can be
uninstalled without its entries in the dependencies table being removed.
--
Ticket URL: <https://trac.macports.org/ticket/34482#comment:7>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list