Re: bulk-*

[Aleksej Saushev <asau%inbox.ru@localhost>]

  Hello,

Alistair Crooks <agc%pkgsrc.org@localhost> writes:

> On Mon, Jan 21, 2013 at 07:04:24AM +0400, Aleksej Saushev wrote:
>> David Holland <dholland-pkgtech%netbsd.org@localhost> writes:
>> 
>> > On Sun, Jan 20, 2013 at 08:30:57PM +0400, Aleksej Saushev wrote:
>> >  > > Add three meta-packages, bulk-small, bulk-medium, and bulk-large.
>> >  > > These are lists of packages that can be used to do restricted bulk
>> >  > > builds on small/slow machines without having to spend time researching
>> >  > > which packages to include.
>> >  > 
>> >  > Why do we do this as meta-packages rather than as a list of
>> >  > packages for pbulk?
>> >
>> > What do you suppose a meta-package *is*?
>> 
>> meta-package is a package, it is meant for end users.
>> What you do is meant for bulk builders rather than for end users.
>> Why do we do this as meta-packages rather than lists of packages for pbulk??
>
> A meta-package is a collection of other packages - no more, no less. 
> I know, because I introduced the concept of meta-packages.
>
>       (from pkgsrc/meta-pkgs/Makefile)
>       COMMENT=        Collections of other packages
>
>       (from pkgsrc/meta-pkgs/Makefile's log)
>       revision 1.1
>       date: 1998/07/24 14:53:21;  author: agc;  state: Exp;
>       Add web-server meta-package.
>
> As such, I think the current location is fine, although the names are
> sub-optimal.

The problem is that meta-package is _not_ _a_ collection of packages.
It is a package itself and this alone restricts what packages can be
built as its dependencies.

>> This is not consistent either. When following this approach we should have
>> meta-pkgs/bulk-all package to build all possible packages.
>
> I don't see how that follows.

The purpose of these 'bulk" packages is not to provide some consistent
installation, they are collections of packages that might be useful.
All packages might be useful, thus we should have bulk-all.

>> If it is really needed to be put into pkgsrc, then it should be in
>> pkgtools category rather (along with pbulk).
>
> No.
>  
>> I propose that we convert these into lists that pbulk understands,
>> and put all of them into some package in pkgtools category. Again,
>> if this is really needed to be versioned and distributed along with
>> pkgsrc.
>
> No, I don't think that's a good idea.  pkgtools is not a dumping
> ground for packages which are remotely related to pkgsrc; it should be
> kept solely for the tools that are needed for pkgsrc's infrastructure.
> Again, please see my first comment above.

Please, try to understand the difference between meta-package and a
collection of packages. One fundamental difference is that it has to
install all of its dependencies in order to get built. We do have
conflicting packages in pkgsrc, don't we?

pbulk also suits better the original intention, which is to track state
rather than build all of the software. If some optional packaged stops
building, pbulk will step over and continue with packages that can be built
while meta-package will just stop.

In addition to this, there's another reason not to do this as a meta-package:
pbulk process scales, you can distribute the work, meta-package build doesn't,
it builds all dependencies one by one. If the purpose of "bulk" packages
is to simplify tracking status on slow systems, then it should be done
in a more optimal way than by building packages serially.

Finally, there's political issue, which we have already observed (request
to include some useless window manager just because one person finds
it small enough). If we follow consistently the approach arising from
these "bulk" meta-packages we may end with several similar but all
different meta-packages per developer.

This demonstrates that the idea wasn't that good from the very beginning.


-- 
HE CE3OH...