Date: Thu, 27 Mar 2008 22:21:01 +0100 From: Ulrich Spoerlein <uspoerlein@gmail.com> To: Pav Lucistnik <pav@FreeBSD.org> Cc: Doug Barton <dougb@FreeBSD.org>, Michel Talon <talon@lpthe.jussieu.fr>, freebsd-ports@FreeBSD.org Subject: Re: Utility for safe updating of ports in base system Message-ID: <20080327212101.GB1931@roadrunner.spoerlein.net> In-Reply-To: <1206052369.83260.30.camel@ikaros.oook.cz> References: <20080320001048.GA39125@lpthe.jussieu.fr> <alpine.BSF.1.10.0803200047360.54264@ync.qbhto.arg> <1206037229.83260.15.camel@ikaros.oook.cz> <47E2C516.4000208@FreeBSD.org> <1206052369.83260.30.camel@ikaros.oook.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for the late reply, catching up on emails ...
On Thu, 20.03.2008 at 23:32:49 +0100, Pav Lucistnik wrote:
> Doug Barton p=C3=AD=C5=A1e v =C4=8Dt 20. 03. 2008 v 13:12 -0700:
> > Pav Lucistnik wrote:
> > > Doug Barton p=C3=AD=C5=A1e 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, a=
nd was=20
> > >> not specifically mentioned the last time we had the discussion on th=
e=20
> > >> list. If the portmgr folks intend that to be a requirement, the curr=
ent=20
> > >> ideas list entry should be amended.
> > >=20
> > > 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.
Amen. To give people in this thread an idea for a very important use
case for businesses running on FreeBSD:
We have a build machine set up, that will build all our required ports
on certain releases with our custom make.conf settings. All these
releases are revisioned themselves, so we can always tell which exact
version of what binaries where present on those systems. Our FreeBSD
machines themselves do not have any /usr/ports and don't (can't) mount
it via NFS. They solely have to rely on pkg_add(1) using FTP to update
their packages.
This is where an automatic tool would come in handy :)
Some people mentioned license issues with certain ports that would
disallow the package building: These issues are non-existant if you are
talking about in-house distribution only. All our jdks are pkg_add(1)ed
and would love to be upgraded just the same.
> > 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.
>=20
> It's not possible at the moment.
>=20
> 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
> pointyhat framework.
I hacked something together once, that would more or less make it
trivial to implement this. I used make(1) (of course) to get the package
dependancy in the form
foo.tbz: bar.tbz baz.tbz
# black magic to build foo.tbz inside clean tree
This immediately allows one to use 'make -j64 openoffice.org.tbz' and
one could add the following dependancy, to have the port rebuild after
every commit (to Makefile, or some suitable file of the port)
foo.tbz: category/foo/Makefile
Though this will trigger quite a hefty rebuild, if you ever touch the
Makefile of the gettext port for example.
Cheers,
Ulrich Spoerlein
--=20
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080327212101.GB1931>