Bug 164973 - duplicated packages in releases
duplicated packages in releases
Product: Fedora Infrastructure
Classification: Retired
Component: extras buildsys (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Schwendt
Jeremy Katz
Depends On:
  Show dependency treegraph
Reported: 2005-08-03 04:39 EDT by Ralf Corsepius
Modified: 2007-04-18 13:30 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-12 04:30:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
pass at a patch (1.90 KB, patch)
2005-08-08 18:41 EDT, Jeremy Katz
no flags Details | Diff

  None (edit)
Description Ralf Corsepius 2005-08-03 04:39:00 EDT
Description of problem:
The build system release all packages that had been successfully built since the
last release and does not purge duplicated packages.

This causes FE to ship superfluous duplicated packages, c.f. Inventor in

IMO, maintainers should be enabled to remove packages from "needsign"
(cf. PR164966) and/or the "release process" (rsp. release manager) should purge
such duplicated packages before releasing such packages.
Comment 1 Jeremy Katz 2005-08-03 12:57:37 EDT
Seth -- I know we had talked about running repomanage on the devel tree, but
does it make sense to run it everywhere?  Or to run it on the needsign queue
before stuff moves over?  If so, I can look at adding that into extras-sign-push
Comment 2 Ralf Corsepius 2005-08-04 00:15:50 EDT
Jeremy, in addition to what you propose, I would prefer to see "success" (queue
containing successfully built packages) being separated from "needsign" (queue
containing packages waiting for signing before release) and the release process
to ask package maintainers for explicit "clearance" or "retracting" before
pushing packages from "success" to "needsign".

Something along the lines of
# plague-client build <package>
=> Package is being built, ends up in "success" or "failure"
=> Package maintainer is being notified on status (success/failure email)

On success, maintainer issues
plague-client release <package>
=> package is being pushed from "success" to "needsign"
plague-client retract <package>
=> package is being removed from "success".

As a side-effect, this  would allow package maintainers to use the build system
for build-testing on platforms a maintainer has no access to.
Comment 3 Seth Vidal 2005-08-04 01:32:55 EDT
Jeremy: Adding repomange to run overtop of the needsign path is fine by me.
Though did we ever get a decision made on how many revisions back of extras
packages we are going to keep?

Ralf: I don't disagree about wanting the buildsys to allow a packager to do test
builds and retract ones but implementing all of your RFEs will take some time.
if you'd like to help out with those implementations I'm sure write access to
the plague tree can be arranged. Are you interested?
Comment 4 Jeremy Katz 2005-08-08 18:41:18 EDT
Created attachment 117562 [details]
pass at a patch

Seth -- here's a pass at a patch to essentially do repomanage over needsign
(not actually using repomanage, since that was going to be weird to integrate
in unfortunately).  But since we only ever want to move over the "newest" from
needsign, I think it should get the intended result.  And it leaves the
question about whether or not we leave old versions available as a side
question that can be decided outside this realm.  

Granted, if we decide not to leave old packages available for extras, then the
far simpler solution is to just run repomanage as the next to the last step of
hte push.
Comment 5 Ville Skyttä 2006-05-20 12:43:48 EDT
We have been repomanaging the repos for quite a while now (keeping 2 versions
for released distro versions and 1 for devel) and if I read the code in
extras-push-new correctly, it also avoids pushing anything else but the latest
build per package from the needsign queue.

Michael, is that correct?  Do you consider extras-push-new being ready to
replace extras-push-all and others?  When all signers start using
extras-sign-new, I think this bug can be closed.
Comment 6 Michael Schwendt 2006-05-21 06:40:14 EDT
Yes, that is correct. Actually, extras-push-new deletes older builds
and then pushes what is left. Works for me. (If we got the repository
lock file, we would be on the really safe side -- see buildsys-list).

The patch from comment 4, which I didn't know about, is incomplete
and would not work as intended. Plus, it contains at least one
crucial typo: infolist.has_key(n) should be infodict. Enhancing
find_files() to drop old builds on-the-fly also was the first thing
I had in mind. Afterall, the code that finds all the rpms is available
already, so I wanted to reuse it, too. *But* since we _move_ the builds
and don't clean up the rest yet, the ignored buils would remain and be
pushed the next time the script is run. That's why I decided to implement
a real cleanup function, which could also be run independently to prune
the needsign tree.
Comment 7 Ville Skyttä 2006-11-12 04:30:32 EST
The new scripts have been in use for quite a while already, and this should no
longer happen.

Note You need to log in before you can comment on or make changes to this bug.