On Wed, 12 Nov 2014 17:49:29 +0900, Alistair Crooks <agc%pkgsrc.org@localhost> wrote:
On Mon, Nov 10, 2014 at 12:12:03PM +0900, OBATA Akio wrote:On Mon, 10 Nov 2014 10:45:03 +0900, Alistair Crooks <agc%pkgsrc.org@localhost> wrote: >On Mon, Nov 10, 2014 at 09:19:03AM +0900, OBATA Akio wrote: >>On Mon, 10 Nov 2014 03:53:47 +0900, Alistair Crooks <agc%pkgsrc.org@localhost> wrote: >> >>>In May 2013, the default of preserving binary packages at package install >>>time was changed, from yes to no. The change was made to stop >>>overwriting existing binary packages (although the "replace" example >>>given surprises me, as the existing binary package is placed in the >>>WRKDIR, not in the packages dir). >>> >>> PatchSet 295 >>> Date: 2013/05/22 23:18:56 >>> Author: obache >>> Branch: HEAD >>> Tag: pkgsrc-2013Q3-base >>> Log: >>> prevent to generate binary package in ${PACKAGES} from the side effect of >>> `install' with USE_DESTDIR=yes. >>> This changes prevent to unwanted overwite of existing binary packages with >>> test installation (`stage-install', `replace' & `undo-replace', and so on). >>> >>> To do both `install' and `package', you can still use `package-install' target, >>> same as USE_DESTDIR=no. >>> >>> Members: >>> bsd.install.mk:1.13->1.14 >>> replace.mk:1.14->1.15 >>> >>>A number of times since then, I've wanted to re-use a binary package, >>>but found it extremely difficult to do when it's not preserved any >>>more. I've heard others express similar feelings, and finding out how >>>to change this is not easy -- you need to use the package-install >>>target -- and the docs continue to reflect the old behavior prior to >>>this change. >> >>If you really want to re-use a binary package, you can use >>"make bin-install" instead of "make package-install". >>* always use binary packages for installation even on dependency if available. >>* binary packages will be created even on dependency if not available. > >The problem here is that, using your suggestion, I would then need to >perform different actions - I would need to use a different target on >the command line. For a long time, we've been using the same targets, >and have grown accustomed to their use. That's why a definition is >needed, which controls the behaviou?r of the target. It's a regression, changed the behaviour, we've been using the same targets for a long time, introduced at staged installation support. "make install" install package "make package" create binary package "make install-package" both It's simple, easy-to-understand behaviour from its naming, not changed before/past staged installation support.We're talking past each other. I do not want a separate target. I want a definition which will provide both behaviors. I provided it. QED.
It is for your question, "why not 'make install' create binary package?"
>Furthermore, I want to use packages I build, not ones which would >download from a different site, and over which I have no control. But >that's secondary, the main reason I would like this is so that I can >type "make install" and have a binary package built for every pre-req >package and the package itself. Don't you like our official build binaries (useless)?I may not have a supported platform (hardware or OS). Some people prefer to build packages from source.Set BINPKG_SITES as empty, or your trusted binary location.Way too intrusive. You're seriously telling me that someone new to pkgsrc should start setting values like this? In addition, there is no documentation on this.
Because you are going to out of documentation. Newbie will not expect that "make install" will create binary package silently on /usr/pkgsrc/packages.
>>>Unfortunately, my muscle memory does not remember this easily. I've >>>become used, over the years to just typing "make install". I'd really >>>prefer it if we could use a definition in mk.conf to drive the >>>decision to preserve binary packages or not. Using a definition means >>>that I can set it once in mk.conf, and have it DTRT. It would prevent >>>me trying desperately to stop "make install" after I've executed it, >>>only to delete it, and type "make package-install". Similarily for >>>pre-requisite packages, which are built for me - I would not have to go >>>back and re-make them. >>> >>>So I've come up with the attached diff which does exactly this. I'm >>>not wedded to the names; however, I'm convinced that a definition would >>>benefit a number of us. >>> >>>Does anyone have any objections to this approach? >> >>Your approach is not "keeping binary packages", but "always create binary packages". >>So you should use such naming, say "PKG_CREATE_BIN_PKGS=yes" instead of >>"PKGSRC_KEEP_BIN_PKGS=no". > >I think this is a question of semantics - a binary package is always >created in the installation process, and it is then used to install >into the final ${PREFIX}. So your suggestion might seem unusual to >some people. As I said, I'm not convinced about the names, but one of >the bye-products of this proposal was that we discuss the preservation >of the binary packages that we build, because I'm not sure why your >change was made in the first place. > >The original commit message mentioned replace and undo-replace, but >the results of the preservation are put into WRKDIR (this was done >specifically so that any binary packages were not overwritten). >stage-install? you mention "test installation", but most consumers of >pkgsrc are the ones who just want software installed; they are not >developers, and we should target them. Ha ha. I'm not a heavy >consumer of the "make stage-install" target, for example. When would >a normal user use that? > >Am I missing something in the bigger picture, though? Why should we >not preserve/create binary packages? The advent of binary package >managers require a package as a basic unit of transfer, and it makes >much sense to me to build binary packages all the time. > >Disk space is rarely an issue these days, even on more expensive flash >devices, so I don't really understand why this change was made in the >first place, I guess. I believe that I have described this matter several times past.Yes, I'm sure you have - but the search engines can't find it. I gave my reasons above, I think you could at least write some text about why you think that a proposal which satisfies both sides in this is not acceptable to you.
Oh, I have misread your patches.
I felt that "PKGSRC_KEEP_BIN_PKGS=yes" means "keep binary package already
in ${PACKAGE} (prevent to overwrite)".
Sorry for my mess.
--
OBATA Akio / obata%lins.jp@localhost