On 2010/07/04 11:18, Toni Mueller wrote:
>
> Hi,
>
> there seems to be some kind of misunderstanding about what I consider
> to be the problem, and what you think what I'm doing.
>
> On Sat, 03.07.2010 at 22:49:19 +0200, Matthias Kilian
> <[email protected]> wrote:
> > If you're trying to use a current ports tree on a -stable system,
>
> To clarify: I'm not using a -current ports tree on a -stable system,
> I'm trying to update single port to -current and build it with the
> -stable ports infrastructure and other packages from -stable, as far as
> I can go. In many cases, this works just fine.
In many cases, it works, but also in many cases, it breaks.
You're also at some risk of packages not getting updated where they
need to be if you later do a binary package update (e.g. when moving
to a new OS version).
> This has been a problem in OpenBSD for quite some time, too. Getting
> security updates, eg. recently for nginx (0.7.65 -> 0.7.67) is one
> such case where I work this idea. Usually, running a "cvs up -PAd ."
> in the affected ports directory is sufficient to get a desirable
> update, but sometimes it doesn't work - eg. in this case, with Python.
Note that the security fix in nginx 0.7.67 is only a problem on Windows.
IMO William has been doing an absolutely *great* job handling security
updates for -stable ports, at first unofficially, and for the last
couple of releases within the project itself.
Binary packages aren't provided for -stable, but if you're running the
same packages on several machines it's well worth setting a plist file
and running your own package builds - e.g. you can do something like
cd /usr/ports && make package SUBDIRLIST=/usr/ports/infrastructure/plist/mine
You can then point other machines at the repository of built packages
with PKG_PATH=scp://host/path/to/arch/ and keep them all in sync.
I heard of at least one person doing this with pkg_add -u run from
a cron job. (I expect the best methodology in production would be
to build, test on one machine, then move to the common repo if it's
good to go into automated updates).
And if you're running a small number of machines, it might well
be simpler to just run -current and use package snapshots, maybe
just updating the OS and installed packages when you need something
new.
> I don't know what else I can do to when I hit a problem, except for
> rolling up my own sleeves and/or mailing this list, which I do both.
>
> > sent to this mailinglist. It's annoying, but we can't avoid it. If
> > we start to keep the ports tree working on -stable (or even older
> > releases), there will be no more improvements to bsd.port.mk nor
> > to pkg_add & friends.
>
> I fully understand that the project is understaffed to handle this
> case. I'm not happy if nobody helps me out, but I do find Marc's
> response _unreasonable_.
The well-staffed projects tend to keep ancient releases around
forever on life support (ever looked at software versions in RHEL?).
The volunteer projects tend to be a lot more up-to-date but at
the expense to the user of having to put a bit more time into
keeping up with everyone else working on the system.
> > > Is there an easy way to discover which packages are outdated and in
> > > need to be rebuilt?
> >
> > /usr/ports/infrastructure/build/out-of-date creates output suitable
> > to be used for SUBDIRLIST (see ports(7)).
>
> Great, thanks!
>
> > > As there are no package repositories for -current,
> > ${YOUR_FAVORITE_MIRROR}/pub/OpenBSD/snapshots/packages/${MACHINE_ARCH}/
> > (yes, amd64 is outdated, no idea why)
>
> Ok, I'll have to dig into this. Now I only need a way to get to a sane
> auto-naming scheme. With -stable systems, I construct the URLs to
> packages using `uname -m` and `uname -r`, but with any -current system,
> this breaks down...
It doesn't make an actual difference for some arch, but this should
be `arch -s` rather than `uname -m`; packages are built per CPU arch
rather than machine arch. (e.g. powerpc not macppc, arm not
armish, mips64 not sgi, etc).
