On Wed, Sep 16, 2009 at 11:14 AM, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] <[email protected]> wrote: > Am Mittwoch, den 16.09.2009, 18:05 +0200 schrieb Marc - A. Dahlhaus > [ Administration | Westermann GmbH ]: >> Am Donnerstag, den 17.09.2009, 01:45 +1000 schrieb Allan McRae: >> > Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote: >> > > Am Mittwoch, den 16.09.2009, 16:18 +1000 schrieb Allan McRae: >> > > >> > >> Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote: >> > >> >> > >>> Am Dienstag, den 15.09.2009, 23:14 +1000 schrieb Allan McRae: >> > >>> >> > >>> >> > >>>> repo-remove... but I am assuming you mean some automated tool to >> > >>>> remove >> > >>>> "useless" deltas? Not yet, and I doubt there will be until someone >> > >>>> starts using deltas in a repo and finds the need to code one. >> > >>>> >> > >>>> >> > >>> Well, i rise my hand then and look into it as we use deltas quite >> > >>> heavily lately here. >> > >>> >> > >>> >> > >> That would be great. From memory, pacman does not use a chain of deltas >> > >> if the total download is greater than 90% of just downloading the full >> > >> package. That is probably a good criteria to use to in order to decide >> > >> which deltas to remove. >> > >> >> > > >> > > Actually first i got confused as repo-remove is documented to take a >> > > pkgname as param to remove the whole package (including deltas) from the >> > > repo. To use the deltapackage-filename as option to remove only that >> > > delta doesn't fitted well into that documentation. I'll try to add this >> > > to the man page and usage outputs during my work on this topic... >> > > >> > > I'd like to add a -d|--delta option to repo-add to create the delta >> > > between the current package and the one to be added. >> > > >> > > For option parsing i plan to make usage of getopt (it is already used by >> > > makepkg so it shouldn't be a problem). >> > >> > I will fully read your proposal later, but I want to flag that makepkg >> > does not use getopt anymore but its own bash parser. This was because >> > of portability issues. I also notice that the reference to getopt at >> > the top of makepkg has not been removed... >> >> Thanks for pointing that out. >> I only did a quick look at the outputs of a recursive grep for getopt but >> missed that it only found it in some comments... > > As makepkg shebangs for /bin/bash, why don't we use the getopts buildin > of bash in the first place, was there a reason to not use it? > > To make usage of it could be a reduction in code size (will look into it > if it's desired) and also would not be a portability issue IMO.
It's not portable
