new package system proposal

[Bob Johnson]

On 4/8/09, Jonathan McKeown <j.mckeown at ru.ac.za> wrote:
> On Tuesday 07 April 2009 23:35:03 Bob Johnson wrote:
>> On 4/4/09, Chris Whitehouse <cwhiteh at onetel.com> wrote:
>> > Hi all
>>
>> [...]
>>
>> > My suggestion is to start with a ports tree that is fixed in time. Make
>> > that ports tree available as part of this package system and compile a
>> > typical desktop set of ports, particularly choosing ones which are large
>> > or have many dependencies. When it is all complete release it and start
>> > again. Surely quite a wide selection of desktops, wm's and apps could be
>> > compiled in a couple of weeks?
>>
>> How is it an improvement over the existing tools? I must be missing
>> something, because it sounds to me like you are merely asking that
>> there be more ports made available as packages than are now offered.
>
> I think what you're missing is the suggestion to bundle a set of pre-built
> packages with a snapshot of the ports tree used to build them. Currently
> it's
> difficult to mix and match packages and ports because the versions of
> dependencies are likely to differ between the package and the local version
> of the ports tree. If you know you have the same ports tree your packages
> were built from, you can much more easily combine pre-built packages and
> local builds from source.

OK, I see now.

>
> This has clear advantages. At the moment, unless you're very lucky with your
> timing, you tend to find that as soon as you want to build one port from
> source (perhaps to fiddle with the configuration) you have to stop using
> prebuilt packages altogether.
>

I've not really had a lot of trouble with that, although it sometimes
causes problems. OK, with something big like KDE it causes problems.

> The drawback I can see is the disk space required to keep several
> generations
> of packages online - if the package-port bundle is rebuilt every three
> weeks,
> let's say, and you want to keep 6 months' worth of packages online, you need
> to keep 9 complete versions available.
>

I think a bigger drawback is the security issue. As soon as any
package in the collection has a significant announced security flaw,
you are faced with the choice of withdrawing the entire collection,
withdrawing only that package, or leaving the flawed package out there
for people to use because it is more convenient for them.

At the very least, it creates a management headache for whomever has
to make the decisions.

> Chris's suggestion is certainly more than just a request for more packages,
> though.
>

It seems to me that a great deal of what his suggestion would
accomplish would be accomplished by building a very extensive set of
packages once a week or so, so that it is easy to do binary updates of
anything that needs updating. For many, that should solve the bulk of
the problem. And because most ports don't change weekly, the
week-to-week changes shouldn't be unmanageably large.

That could also be a starting point for implementing his full
suggestion. Keeping around week-to-week deltas rather than an entire
collection would reduce the storage requirement substantially.

PC-BSD seems to already keep up-to-date binary packages of their
applications. Do they accomplish that by only offering a small subset
of the full ports collection?

-- 
-- Bob Johnson
   fbsdlists at gmail.com