Utility for safe updating of ports in base system

[Doug Barton]

Pav Lucistnik wrote:
> Doug Barton píše v c(t 20. 03. 2008 v 01:05 -0700:
>> On Thu, 20 Mar 2008, Michel Talon wrote:
>>
>>> i would venture to say that such an utility
>>> should be able to upgrade things based of *binary* packages, and
>>> consequently that portmaster is not a suitable candidate.
>> That ability is not included in the current requirements document, and was 
>> not specifically mentioned the last time we had the discussion on the 
>> list. If the portmgr folks intend that to be a requirement, the current 
>> ideas list entry should be amended.
> 
> Yes, I think ability to work with packages on a remote FTP site with no
> local /usr/ports, solely relying on an INDEX file, is a solid "must
> have" requirement. I have added that to the entry in the Ideas page.

Fair enough, but can we please come quickly to a consensus on what
_all_ of the requirements should be? Two things I'd like to avoid. One
is the feeling that no matter how many hoops I jump through, there is
always going to be one more placed in my path because we really don't
want portmaster in the base. The other is frustration on the part of
any student brave enough to tackle this task.

> At the same time, ability to work on a local /usr/ports _without_ INDEX
> file is also a requirement.

That should be mentioned then, but the good news is that portmaster
already fulfills that one. It never uses the INDEX file for anything.

> I think we should be pushing our packages and package-only modes of
> operation to the mainstream users. Especially now when we can afford to
> build a complete package set for all existing platforms/architectures on
> a 48-hour cycle basis.

I would be more sympathetic to this idea if we could somehow push
security-sensitive package builds up to the top of the list (so they
would be available ASAP), but the last time I inquired about this I
was told it isn't possible.

> There should also be an overhaul of current ftp mirrors infrastructure,
> which might not be able to sustain the constant flow of new packages.

You also need to look at the other side of that, which is an
exponential increase in the number of package downloads, and the
incumbent costs in terms of bandwidth, processor time, etc.

Doug

-- 

    This .signature sanitized for your protection