> Ok, so this program would need to:
> 1 Scan all the ebuilds and see which ones use SCM.
> 2 Auto generate a snapshot and notify the maintainer so he/she can
> test the snapshot and make sure everything is working just fine.
> 3 Modify the ebuild to point to the snapshot instead of the source repository.
> 4 Update the Manifest to reflect this update
> 5 Periodically check for changes.
No.
Let's say the ebuild name is bioperl-1.7.ebuild and the writer
specifies (purely hypothetical/provisional syntax)
inherit git scm-snapshots
EGIT_REPO_URI="git://code.open-bio.org/bioperl/"
EGIT_BRANCH="1.7"
SRC_URI=""
What scm-snapshots.eclass will do is try to add
"mirror://gentoo/bioperl-1.7.tar.bz2" to SRC_URI and fetch it, and if
that fails, hand it over to the git eclass which will perform the
fetch from the repo as it normally would. It would be the daemon's
responsibility to see that the ebuild is using scm-snapshots, generate
the snapshot, upload it to gentoo mirrors, and update the package
manifest to include the snapshot.
Alternatively, since an automated manifest change is necessary anyway
once the snapshot is generated in this scenario, the daemon could edit
the ebuild to change the SRC_URI and effectively disable any SCM
eclass that is being used.
> I also assume that there will be an option for the maintainer to keep
> the ebuild live in the way it is now, without snapshots?
Yes. They wouldn't need to do anything. Without scm-snapshots.eclass,
nothing would happen.
> Also, would the scm url be left as a backup, in case the snapshot
> cannot be found? Or should we provide an classical live ebuild as well
> as the snapshot version, in order to have a fallback?
Yes, see the way I described it above. If there is no snapshot found
on the mirrors, it would hand over to the scm eclass. A "classical"
live ebuild's behavior wouldn't change at all.
-ak
|
