2

Although PORTAGE_RSYNC_OPTS, a make.conf option, allows one to change the rsync options but removing --delete from it causes emerge to fail. I think with it remarking about missing md5-cache entries or such.

I would like to keep the old ebuild files for a bit longer than the upstream portage tree does.

  • There is a reason this ebuild got deleted from the main tree. What do you get from keeping those ebuilds? Remember that you can resurrect any file that ever in the tree from sources.gentoo.org – Flow Jul 8 '13 at 17:53
  • @Flow I know they remove the files because they no longer want to maintain them. I can continue to be able to build the packages that I already installed at least until those packages are suitably replaced by newer versions where in suitably is of personal definition. – Dan D. Jul 8 '13 at 18:09
0

There is a reason this ebuild got deleted from the main tree. If your goal is to keep the ebuild because you want to be able to build them after they are deleted from the main tree, then I suggest you create a local overlay and extract the deleted ebuilds from sources.gentoo.org.

0

Back in the day, there would be repositories of the portage tree which you could clone/checkout at your hearts content. Within these repositories you would always be able to pull out old ebuilds. As portage/gentoo puts manifests and checksums everywhere, you cannot have an ebuild that upstream doesn't want to be a part of the portage tree. Only as an overlay.

I googled that for you and found this question on Superuser SE which tells you how to do the overlay and also includes a link to a portage CVS repository.

More details:

You are not using rsync, you are using emerge The former gets used by the latter, which makes it a part of emerge, actually, a part of portage, which is what you are really using to manage (not just copy!) your packages and package information. By looking at rsync you are looking at a rather deep detail of portage and you cannot just change that detail. Instead, you have to consider the entire system. That's why merely tweaking rsync's behaviour will never achieve what you want and causes an error in emerge.

Another part of the system portage, which you are using, are checksums. For every file there needs to be a checksum. When you run emerge --sync you are not only copying and deleting ebuilds, you are also syncing the list of files within the portage tree and their corresponding checksums. Files, that are removed upstream, and therefore from the portage tree, are also removed from the list of files within the portage tree (because they are not part of the portage tree anymore).

This is why you fail: By removing --delete you end up with files in your portage tree for which no checksums are avaiable. But, as stated above, checksums are a part of the system, so you need them.

There is also a checksum on the list of files and probably one or the other additional checksum, so its probably tedious to circumvent.

If you want to keep your old ebuilds, those that the maintainers concluded it is a good idea to remove, you have two choices:

  1. you can break the portage system,

    a) force rsync's behaviour,

    b) hack emerge so that the list of files will always include your ebuilds with checksums and

    c) build something to make sure all checksums are always there and ok, including that of the list of files

    d) come up with a consistent system that will keep your special ebuilds, but remove the old, deprecated and faulty ones so that you will have a stable and maintainable operating system

  2. you act within the portage system which allows you to modify the portage tree, by the means of overlays.

You are clearly having a xy problem. You state yourself that you would like to keep some ebuils of important software around. But instead of asking how to do that, you are asking how to modify the behaviour of a tool that is used by emerge, which is a tool of portage.

One might extent the figure to a wxyz problem, with w being your actual problem, you run off along x (portage), passing y (emerge) and finaly run into a wall at z (rsync). It's time to go back a few steps.

Others have had the same intent (keep old ebuilds) as you do right now. There is a valid and documented way of achieving that goal without messing up the entire system. I suggest you go that way.

  • I'm not adding anything to the upstream in the portage tree. I would use an overlay for that. But what I want is that when I sync the tree I want to keep all the ebuilds that are already in it which were previously fetched in a prior sync in that tree while adding any new ones. – Dan D. Jul 8 '13 at 14:37
  • You want more ebuilds in your portage tree than there ordinarily would be. That means you ADD something to the "normal" portage tree. It doesn't matter when or how the files were created – Bananguin Jul 8 '13 at 21:43
  • No, I just want rsync to not delete the files that rsync put in the tree the last time it was ran. Which I know I can do by removing the --delete option. But that results in a tree which emerge fails to work on due it finding some cached hashes missing. – Dan D. Jul 8 '13 at 21:47
  • You dont' want rsync to do anything, you want portage, emerge in this case, to act differently. After all, you are running emerge --sync and not rsync, are you. I added more details to my answer to clarify the context. – Bananguin Jul 9 '13 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.