Package Database Infrastructure SOP

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(SOP => ISOP)
(instructions for retiring package in koji)
Line 101: Line 101:
 
rm OLDNAME
 
rm OLDNAME
 
ln -s ../rpms/NEWNAME .
 
ln -s ../rpms/NEWNAME .
 +
</pre>
 +
 +
If the package has existed long enough to have been added to koji, run something like the following to "retire" the old name in koji.
 +
<pre>
 +
koji block-pkg dist-f12 OLDNAME
 
</pre>
 
</pre>
  
Line 177: Line 182:
 
-- Make sure only the number of rows you saw before were updated
 
-- Make sure only the number of rows you saw before were updated
 
pkgdb=# COMMIT;
 
pkgdb=# COMMIT;
 +
</pre>
 +
 +
If the package has existed long enough to have been added to koji, run something like the following to "retire" it in koji.
 +
<pre>
 +
koji block-pkg dist-f12 PKGNAME
 
</pre>
 
</pre>
  
 
[[Category:Infrastructure SOPs]]
 
[[Category:Infrastructure SOPs]]

Revision as of 23:27, 11 May 2009

Infrastructure InfrastructureTeamN1.png
Shortcut:
ISOP:PKGDB

The PackageDB is used by Fedora developers to manage package ownership and acls. It controls who is allowed to commit to a package and who gets notification of changes to packages.

PackageDB project Trac: https://fedorahosted.org/packagedb/

Contents

Contact Information

Owner: Fedora Infrastructure Team

Contact: #fedora-admin

Persons: abadger1999

Location: Phoenix

Servers: admin.fedoraproject.org Click on one of the current haproxy servers to see the physical servers Purpose: Manage package ownership

Troubleshooting and Resolution

Common Actions

Adding a new Pseudo User as a package owner

Sometimes you want to have a mailing list own a package so that bugzilla email is assigned to the mailing list. Doing this requires adding a new pseudo user to the account system and assigning that person as the package maintainer.

Idea.png
In the following examples, replace ("xen", "kernel-xen-2.6") with the packages you are assigning to the new user and 9902 to the userid you select in step 2
  • Log into a box that can access db2.
  • Log into the db as a user that can make changes
$ psql -U apache -h db2 fedorausers
fedorausers>
  • Find the current pseudo-users
fedorausers>  select id, username from person where id < 10000 order by id;
id  |     username
------+------------------
9900 | orphan
9901 | anaconda-maint
  • Create a new account with the next available id after 9900
fedorausers> insert into person (id, username, email, human_name, password, creation,
approval_status, otrs_orgid) values (9902, 'xen-maint', 'xen-maint@redhat.com',
'Xen Maintainers', '', now(), 'approved', 'Fedora');
  • Connect to the pkgdb as a user that can make changes
$ psql -U pkgdbadmin -h db2 pkgdb
pkgdb>
  • Add the current package owner as a comaintainer of the package. If this user is not currently on he acls for the package you can use the following database queries:
insert into personpackagelisting (userid, packagelistingid)
select pl.owner, pl.id from packagelisting as pl, package as p
where p.id = pl.packageid and p.name in ('xen', 'kernel-xen-2.6');
insert into personpackagelistingacl (personpackagelistingid, acl, statuscode)
select ppl.id, 'build', 3 from personpackagelisting as ppl, packagelisting as pl, package as p
where p.id = pl.packageid and pl.id = ppl.packagelistingid and pl.owner = ppl.userid
and p.name in ('xen', 'kernel-xen-2.6');
insert into personpackagelistingacl (personpackagelistingid, acl, statuscode)
select ppl.id, 'commit', 3 from personpackagelisting as ppl, packagelisting as pl, package as p
where p.id = pl.packageid and pl.id = ppl.packagelistingid
and pl.owner = ppl.userid
and p.name in ('xen', 'kernel-xen-2.6');
insert into personpackagelistingacl (personpackagelistingid, acl, statuscode)
select ppl.id, 'approveacls', 3 from personpackagelisting as ppl, packagelisting as pl, package as p
where p.id = pl.packageid and pl.id = ppl.packagelistingid
and pl.owner = ppl.userid
and p.name in ('xen', 'kernel-xen-2.6');

If the owner is in the acls, you will need to figure out which packages already acls and only add the new acls for that one.

  • Reassign the pseudo-user to be the new owner
update packagelisting set owner = 9902 from package as p
where packagelisting.packageid = p.id and p.name in ('xen', 'kernel-xen-2.6');

Renaming a package

On db2:

sudo -u postgres psql pkgdb
select * from package where name = 'OLDNAME';
[Make sure only the package you want is selected]
update package set name = 'NEWNAME' where name = 'OLDNAME';

On cvs-int:

CVSROOT=/cvs/pkgs cvs co CVSROOT
sed -i 's/OLDNAME/NEWNAME/g' CVSROOT/modules
cvs commit -m 'Rename OLDNAME => NEWNAME'
cd /cvs/pkgs/rpms
mv OLDNAME NEWNAME
cd NEWNAME
find . -name 'Makefile,v' -exec sed -i 's/NAME := OLDNAME/NAME := NEWNAME/' \{\} \;
cd ../../devel
rm OLDNAME
ln -s ../rpms/NEWNAME .

If the package has existed long enough to have been added to koji, run something like the following to "retire" the old name in koji.

koji block-pkg dist-f12 OLDNAME

Removing a package

Warning (medium size).png
Do not remove a package if it has been built for a fedora release or if you are not also willing to remove the cvs directory.

When a package has been added due to a typo, it can be removed in one of two ways: marking it as a mistake with the "removed" status or deleting it from the db entirely. Marking it as removed is easier and is explained below.

On db2:

sudo -u postgres psql pkgdb
pkgdb=# select id, name, summary, statuscode from package where name = 'b';
  id  | name |                     summary                      | statuscode
------+------+--------------------------------------------------+-----------
 6618 | b    | A simple database interface to MS-SQL for Python |          3
(rows 1)

-- Make sure there is only one package returned and it is the correct one.
-- Statuscode 3 is "approved" and it's what we're changing from
-- You'll also need the id for later

pkgdb=# BEGIN;
pkgdb=# update package set statuscode = 17 where name = 'b';
UPDATE 1
-- Make sure only a single package was changed.
pkgdb=# COMMIT;

pkgdb=# select id, packageid, collectionid, owner, statuscode from packagelisting where packageid = 6618;
  id   | packageid | collectionid | owner  | statuscode
-------+-----------+--------------+--------+-----------
 42552 |      6618 |           19 | 101437 |          3
 38845 |      6618 |           15 | 101437 |          3
 38846 |      6618 |           14 | 101437 |          3
 38844 |      6618 |            8 | 101437 |          3
(rows 4)

-- Make sure the output here looks correct (packageid is all the same, etc).
-- You'll also need the ids for later

pkgdb=# BEGIN;
pkgdb=# update packagelisting set statuscode = 17  where packageid = 6618;
UPDATE 4
-- Make sure the same number of rows were committed as you saw before.
pkgdb=# COMMIT;

pkgdb=# select * from personpackagelisting where packagelistingid in (38844, 38846, 38845, 42552);
 id | userid | packagelistingid.
 ----+--------+------------------
 (0 rows)

-- In this case there are no comaintainers so we don't have to do anymore.  If
-- there were we'd have to treat them like groups handled next:

pkgdb=# select * from grouppackagelisting where packagelistingid in (38844, 38846, 38845, 42552);
  id   | groupid | packagelistingid.
-------+---------+------------------
 39229 |  100300 |            38844
 39230 |  107427 |            38844
 39231 |  100300 |            38845
 39232 |  107427 |            38845
 39233 |  100300 |            38846
 39234 |  107427 |            38846
 84481 |  107427 |            42552
 84482 |  100300 |            42552
(8 rows)

pkgdb=# select * from grouppackagelistingacl where grouppackagelistingid in (39229, 39230, 39231, 39232, 39233, 39234, 84481, 84482);
-- The results of this are usually pretty long. so I've omitted everything but the rows
(24 rows)
-- For groups it's typically 3 (one for each of commit, build, and checkout) *
-- number of grouppackagelistings.  In this case, that's 24 so this matches our expectations.
pkgdb=# BEGIN;
pkgdb=# update grouppackagelistingacl set statuscode = 13 where grouppackagelistingid in (39229, 39230, 39231, 39232, 39233, 39234, 84481, 84482);
-- Make sure only the number of rows you saw before were updated
pkgdb=# COMMIT;

If the package has existed long enough to have been added to koji, run something like the following to "retire" it in koji.

koji block-pkg dist-f12 PKGNAME