Ideas and questions on pkgsrc

[Aggelos Economopoulos]

Chris Turner wrote:
> Justin C. Sherrill wrote:
>>  - General ideas about the bulk builds and binary installs; I've been
>> staring at it so long I can't see the forest because there's all these
>> trees in the way.
> 
> Yeah.. Lots of these ideas crossing my mind today as well -
> this DNS-in-base thing kind of spurs a lot of thinking about direction
> 
> (or maybe thats my life right now :)
> 
> aaanyhow..
> 
> some things come to mind:
> 
> 1) I've got some 'pkgsrc profile' scripts lying around. They are
>   basically lists of package names, which use 'rcorder' to create /
>   install a heirarchy of packages.. e.g. just to pick a random example,
>   your 'trac' profile might pull in your 'apache' profile,
>   and also your 'python' and 'developer tools' profile.
> 
>   I'm in the process of dusting off code / revamping my website -
>   I'll try to get that released somehow - maybe getting it
>   into pkgsrc/pkgutils might make sense -
> 
>   and providing a few stock ones of these might help..

Well, w/o having seen the code, this sounds like a bit of a hack :) Also
I'm not sure what problem you're solving. Pkgsrc already has working
package dependencies. The serious issue is with handling upgrades.

>   which brings to mind:
> 
> 2) nrelease vs pkgsrc vs contrib interfacing -
> 
>   If the plan is to modularize alot of contrib, it probably makes sense
>   to get some kind of toolkit in place for this. I for one like having
>   some things 'always built', and running nrelease every now and again
>   has always seemed a bit like something that I do as an afterthought -
>   and having this be a more 'usual' thing, might make the release
>   go more smoothly / etc.
> 
>   e.g. if my 'make buildworld' would build dfly world, a pkgsrc
>   bootstrap, and some core tools, like say BIND :) - that would be
>   pretty hip - and if 'make installworld' would drop those into place
>   without blowing up my base install, that would be hip too.

Eh, to do this properly you'd have to upgrade all packages depending on
your 'base' packages and all packages depending on those packages and so
on ("transitive closure").

Keeping stuff in base has the disadvantage that pkgsrc doesn't really
know when they get upgraded, so if you upgrade something in base to an
incompatible version things will break unless you manually upgrade every
pkgsrc package depending on that (directly or indirectly). Nevermind
that pkgsrc might not yet have a newer version that will work with the
thing you upgraded.

I'd say that is a strong argument for a slim base (or making sure
/usr/pkg is almost completely independent of base).

Aggelos