pkgsrc-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/shells/standalone-tcsh



I think we're talking at cross-purposes here - my beef isn't with
large companies, small companies, or anyone else doing things with
pkgsrc.

Rather, I have problems *optimising* for them at the expense of
others, or using bulk building as justification for doing something -
I'd hoped that we long ago got rid of the horrible BATCH stuff we
inherited, but it seems there are some holdouts:

> grep -r BATCH mk
mk/build/build.mk:.if !empty(INTERACTIVE_STAGE:Mbuild) && defined(BATCH)
mk/build/test.mk:.if !empty(INTERACTIVE_STAGE:Mtest) && defined(BATCH)
mk/extract/extract.mk:.if !empty(INTERACTIVE_STAGE:Mextract) && defined(BATCH)
mk/configure/bsd.configure-vars.mk:SCRIPTS_ENV+=  ${BATCH:DBATCH=yes}
mk/configure/configure.mk:.if !empty(INTERACTIVE_STAGE:Mconfigure) &&
defined(BATCH)
mk/fetch/fetch.mk:.if !empty(INTERACTIVE_STAGE:Mfetch) &&
defined(BATCH) && !defined(FETCH_MESSAGE)
mk/install/install.mk:.if !empty(INTERACTIVE_STAGE:Minstall) && defined(BATCH)
mk/misc/can-be-built-here.mk:.  if defined(BATCH) &&
!empty(MACHINE_PLATFORM:M${p})
mk/patch/patch.mk:.if defined(BATCH)
mk/patch/patch.mk:.if defined(BATCH)
>

I have no problems with making things easier for bulk building, and
appreciate the work that you and others do in this - bulk builds play
a large part as regression testing pkgsrc, which would otherwise not
be done.

On 12 September 2016 at 12:35, Jonathan Perkin <jperkin%joyent.com@localhost> wrote:
> * On 2016-09-12 at 18:01 BST, Alistair Crooks wrote:
>
>> Well, strongly recommend away, but pkgsrc was not designed for the people
>> doing bulk builds, but rather for users. Nor should it ever be anything
>> other than for those same users.
>>
>> If pkgsrc becomes a place where only people with access to large company
>> cloud deployments, or huge bulky machines, are happy, then I think we have
>> a serious problem. Analogous to Linux being taken over by the corporate
>> suits wanting to stress the number of lines of code they contribute. I
>> really don't want to go there.
>
> I agree that we'll probably need to agree to disagree, but I strongly
> reject the notion that bulk builds are only for large companies.
> Whether it was with the old mk/bulk code or now with pbulk, and
> regardless of whether it was for production use or simply for my
> personal desktop, and irrespective of whether it was on a crappy Sun
> Ultra 10 or across multiple fast systems, I have for over a decade
> built my packages with bulk build code inside chroots, for a single
> package or 100 (via limited_list or *_SPECIFIC_PKGS) or all 17,000 of
> them.
>
> To me it's the only way to ensure consistency and avoid issues while
> trying to perform a live upgrade, and I simply don't trust pkgsrc to
> do it right otherwise.  Yes I will concede that these things _should_
> be handled by pkgsrc without the need for special environments, but we
> are a long way from that and until we are then I'd really rather we
> didn't see bulk builds as only for people with huge systems.  You can
> run them on anything and everything (and Sevan probably has!)
>
> I've tried to explain the benefits of doing it this way for a long
> time, as well as providing docs and infrastructure to make it simpler
> for folks to get started, so I guess I've failed pretty badly at doing
> so if people still see it only as being for an exclusive club rather
> than being something you can run every single day on crappy hardware.
>
> --
> Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com
>



Home | Main Index | Thread Index | Old Index