Utility for safe updating of ports in base system
pav at FreeBSD.org
Thu Mar 20 15:32:53 PDT 2008
Doug Barton píše v čt 20. 03. 2008 v 13:12 -0700:
> 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.
I will install portmaster on my machine now and give it a tryout.
Tell you what I like and what I dislike about it.
I'm afraid the moment I start pushing for making something that is not
portupgrade a new de-facto standard, it will turn into a muddy politics
really fast. Well I guess I have to bite a bullet.
And I don't think anyone started talking to the src guys about including
it in base system yet.
> The other is frustration on the part of
> any student brave enough to tackle this task.
It is not marked as a "Summer of Code suggested project". Only the
parallelization task is.
> > 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.
It's not possible at the moment.
There are dreams of having an on-commit action that would trigger a
rebuild of the changed port and only the changed port on all platforms.
But I feel this would be fairly hard to implement inside the current
> > 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.
My impression is that current mirrors are vastly underutilized, and that
it's not a big problem to get more mirrors if we ask.
But the current cvsup/rsync method of distributing changes from
ftp-master onto mirrors is not good enough. It introduces a huge
latency, it's unpredictable and inconsistent.
We would need to build a CDN for packages, ideally.
Also, if we want to get serious about packages, we need to ensure atomic
updates of package sets on the ftp master and on the mirrors. We
currently don't do that.
Pav Lucistnik <pav at oook.cz>
<pav at FreeBSD.org>
Quantum physics was developed in the 1930's, as a result of a bet
between Albert Einstein and Niels Bohr, to see who could come up with
the most ridiculous theory and still have it published.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?=
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20080320/0dd43b7f/attachment.pgp
More information about the freebsd-ports