On Friday 19 June 2009 00:27:06 Goswin von Brederlow wrote: > Joseph Rawson <umeboshi3@gmail.com> writes: > > BTW, the subject of this thread is "apt-get wrapper for maintaining > > Partial Mirrors". The solution I'm proposing is "a simple tool for > > maintaining Partial Mirrors" (which could possibly be wrapped by apt-get > > later). > > > > I think that just pursuing an "apt-get wrapper" leads to some > > complications that could be avoided by creating the "partial mirror tool" > > first, then looking at wrapping it later. One complication might be "how > > do handle apt-get remove", and another might be "how to handle sid > > libraries that disappear from official repository, yet local machines > > must have them". > > Ahh, so maybe I completly misread that part. > It was my fault for not making this point clear, as I should've done. FWIW, I would be much more interested in making a tool that would make it easier to manage local/partial debian mirrors (i.e. one that helped resolve the dependencies), rather than have an apt-get wrapper. I also think that once such a tool is made, it would make it easier to build an apt-get wrapper that works with it. I don't think that viewing the problem with an "apt-get wrapper" solution is the best way to approach it, but I do think that it would be valuable once the underlying problems are solved. > Do you mean a wrapper around apt-get so that "apt-get install foo" on > any client would automatically add "foo" to the list of packages being > mirrored on the server? > It was the original poster who mentioned the apt-get wrapper, but I took it to mean exactly what you said above. The tool I was envisioning would take a short list of packages (a text file with package names separated by newlines, or a collection of such text files) combined with a list of apt sources and generate the partial mirror from just that information. There are still some things that should be explicitly included in those lists, such as either gamin, fam, or both, as an example. > If so then you can configure a post invoke hook in apt that will copy > the dpkg status file of the host to the server [as status.$(hostname)] > and then use those on the server to generate the filter for > reprepro. I think I still have a script for that somewhere but it is > easy enough to rewrite. That's good for binaries, but I don't know about the source. It wasn't long ago that I noticed a problem with reprepro not obtaining the corresponding source packages when you use a filter list taken from "dpkg --get-selections". I remember that the source for jigdo wasn't in my partial mirror, because there were no binaries named "jigdo", rather "jigdo-file" and "jigdo-lite". Since there were no sources with that name, the jigdo source was never mirrored on my partial mirror. I don't know if that behavior has been fixed now, since there is now a binary named jigdo, instead of jigdo-lite. Also, it's more difficult for the local repository to determine the difference between the automatically selected and manually selected packages in this type of setup, since you would be sending a longer list of "manually selected packages", instead of distinguishing which ones are actually selected. I guess that it doesn't matter much, as a package would only be removed from the repository once it's not listed on any of the lists. There were times when I didn't want certain packages to be removed from the repository, regardless of whether they were installed or not, so I used to run xxdiff on the packages files, so the newer ones were added. In my way of thinking, I'm not looking to merge upstream repositories together in one repository. Besides, there are already tools, such as apt-move that would be better for this job. Long ago, apt-move was the primary tool that I used to keep a local repository, and it worked pretty well, as long as all the machines that were using it were on the same release. I have found that reprepro is the absolute best tool for maintaining a debian mirror. The only problem I have with it is when I want to maintain a partial mirror, and I don't want a merged repository, is that I have to spread the packages lists to different places, and when you start adding machines, you start adding more lists to the configuration, when it would probably be better to maintain a set of "master" lists that are generated from the many lists that come from the machines. > > MfG > Goswin -- Thanks: Joseph Rawson
Attachment:
signature.asc
Description: This is a digitally signed message part.