2013/9/7 Laurent Blume <laur...@opencsw.org> > > On 2013-09-07 8:29 PM, Maciej (Matchek) Bliziński wrote: > > So far, I've tried to make the package promotion as simple as > > possible. Ideally, it was an equivalent of taking a snapshot of > > unstable and making it the testing catalog. > > Since that's basically what I'm doing in production, I'm all for it.
In practice it wasn't that simple, there usually were packages I wanted to skip. Another thing is deletions: we need to propagate them as well, but the database currently doesn't hold the information about when a package was removed from a catalog. This might be an inconvenient feature to implement. We currently have a table which connects a svr4 file, catalog release, OS release and architecture. mysql> describe srv4_file_in_catalog; +-------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+-------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | arch_id | int(11) | NO | MUL | NULL | | | osrel_id | int(11) | NO | MUL | NULL | | | catrel_id | int(11) | NO | MUL | NULL | | | srv4file_id | int(11) | NO | MUL | NULL | | | created_on | datetime | NO | | NULL | | | created_by | varchar(50) | NO | | NULL | | +-------------+-------------+------+-----+---------+----------------+ 7 rows in set (0.37 sec) A row in this table means that such-and-such package is in a specific catalog. If we want to keep the information about deletions, we'll have to keep the row, but the row would need to contain a flag indicating that the package has been removed at certain time. Maciej _______________________________________________ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.