The idea is to reduce portage tree size. Most of time, a bump would need a very small change in ebuild or none at all so why make a new ebuild instead of making a patch against other ebuild? I suggest portage to support another ebuild format: .ebuild.patch. For example, we already have foo-1.0.0.ebuild. Instead of creating foo-1.0.1.ebuild, which is almost as same as foo-1.0.0.ebuild, we create foo-1.0.1.ebuild.patch against foo-1.0.0.ebuild. Portage should be able to take foo-1.0.0.ebuild, patch it with foo-1.0.1.ebuild.patch to regenerate foo-1.0.1.ebuild. Using whether .ebuild or .ebuild.patch is up to ebuild maintainers. Some problems i see: older portage versions will not be able to process new format. EAPI doesn't help. So it would take long before this feature is usable. Another problem is, what if i remove foo-1.0.0.ebuild? I think if repoman is clever, it will not allow to commit. Devs have to regenerate foo-1.0.1.ebuild themselves or build a tool to do that. Any idea? Do I need to mark it as RESOLVED LATER now? :)
The vast majority of ebuilds will take one or two sectors (depending on sector size) on the harddisk. The impact of a change to some sort of diff'ed ebuilds will be negligble, imho. I'd also assume having to restore the full ebuilds from the diffs would slowdown Portage when updating its cache. Having a patch repository, instead putting the patches into ../files/ would be a more obvious step.
> Any idea? > Do I need to mark it as RESOLVED LATER now? :) > Funny ;) Basically looking for something better than /usr/portage, storing the info you want. We aren't going to write the beast for you but we are working on some classes ( notably in Savior branch ) that you can subclass so that you can do whatever you like for your repo. However they aren't done, so this is marked LATER until savior is done enough where testing can begin, ( ie in ~arch ).
*** Bug 126060 has been marked as a duplicate of this bug. ***
