> > would it be difficult to (optionally) also install the changes file into > > the pool structure when using the "include" command? > > Sorry for my late reply, I must have missed this mail somehow.
it happens. > It could either be added to the files needed by some source or binary > package (though that would be a bit ugly, as it might reference files > no longer be there, and might need some magic to keep it seperate from > the other files) > Another possiblity would adding a new index type, that is not exported > in some index file, but just contains the files needed by this version. > This would mean that independently from the binary or source packages > in the other lists the changes files and all files it references are > kept inside the pool, until the changes file entry is deleted. this sounds best to me. > This second possibility would make it a bit harder to get rid of those > files, but it could also be a possiblity to keep old packages there. > (They would not appear in the Packages.gz and Sources.gz files that > way, but would still be in the pool/) sounds good enough for me :) > I think each should be implementable in about a week (unless the week > is as messy as the recent ones). Just say which you prefer. talk about service :) > P.S: In both ways the .changes file may end in an different directory > than most of files, as there are packages spreading their files over > main and contrib, and I think more than using the directory of the > first file would be quite complicated. oh well, thanks! live well, vagrant
signature.asc
Description: Digital signature
