but it ended up in installing packages (instead of only building them) even some I hadn't before (qt3, mysql...) and seemed to continue endlessly.

- Last question, I wanted to subscribe to the ports-security list, but there is no activity since 2006. Is there a way to be aware of the availability of updates without updating the port tree and running out-of-date ?

I've never used make update when updating anything, because that's used for bulk updates, and either I'm doing fresh builds of select ports, or, I want to control what ports get updated. For both changed ports and unchanged ports with updated dependent libraries, I typically use make package followed by pkg_add -ir.

If I am building a group of packages, I complete all the package builds and follow with pkg_add -iu.

Is this best practice? I'm unsure. It works for me.

Quote:

- What should I do for evolution-data-server to be correctly linked to eggdbus-0.6p1 ?

I'm going to guess: evolution-data-server was NOT rebuilt. That port had no update, and your make found a matching package at your $PKG_PATH, and skipped the build. It's just a guess, of course.

Quote:

- How come new packages came along while I update ? (CUPS for example in the case of Firefox)

New versions of software may have new dependencies, but more likely, CUPS is a build dependency, but not a run dependency.

Quote:

- Is there a way to send the output of the out-of-date script to the update process ?

Yes. You can edit the output to look like one of the SUBDIR Makefiles in any of the ports tree branches, such as /usr/ports/databases/Makefile

There was an update for eggdbus, isn't it enough for evolution to be rebuild ?

No, you must manually build if you want to bring it up to date. There is no forced update, because the Makefile doesn't require it. Look in /usr/ports/database/evolution-data-server/Makefile. You will find devel/eggdbus is one of 7 LIB_DEPENDS, and it does not have a minimum version or patchh level -- only one library has a minimum version requirement.

As I said before, If you want to force the building of a port, you are likely to find "make package" more effective than "make update" -- there is nothing in your dependency chain nor in this unchanged Makefile that will force a rebuild.

Quote:

I don't understand why packages got installed and not only created in in/usr/ports/packages/amd64/all

Build dependencies are required to be installed and operational in order to build the port in question.

Quote:

And I got CUPS, Samba and a lot of packages I didn't want to install :'(

Yes, because the dependency chains can be quite long, and build dependencies are usually much larger than run dependencies. You are building, you are no longer installing pre-built packages built by someone else.

To understand what gets installed in order to build, use "make print-build-depends" and compare that to "make print-run-depends". I had attempted to copy/paste some console output, but it's not working for me from this particular browser. But you will see for yourself when you run make with those targets.

To understand what gets installed in order to build, use "make print-build-depends" and compare that to "make print-run-depends". I had attempted to copy/paste some console output, but it's not working for me from this particular browser. But you will see for yourself when you run make with those targets.

Thanks, it is much clearer now. A shame there is no option to delete the build dependencies, once the final package is created. But I guess I won't have to build them again next time I update the same packages. (well, if they don't need to be updated themselves)

And I'll do a samba share and buy a printer to avoid wasting disk space

Quote:

As I said before, If you want to force the building of a port, you are likely to find "make package" more effective than "make update" -- there is nothing in your dependency chain nor in this unchanged Makefile that will force a rebuild.

But /usr/ports/infrastructure/build/out-of-date keeps telling me that my evolution-data-serverport is outdated because of eggdbus.
Was the package not built with the new version of eggdbus, previously installed ?

I deinstalled vinagre (which was the reason for all this) and all its dependencies and did the same for the outdated packages and eggdbus.
I used all the make clean possible and installed vinagre from ports.
After this, out-of-date, still points out the same packages. I guess the script is somehow mistaken...

This sounds a bit strange to use a security focused system and not to bother apply security patches then. That's what people running release do.

The other thing I wonder is if the stable branch gets ports security fixes as soon as there is a security hole and if all ports get a fix.

On OpenBSD site, you are encouraged to start with release and apply patches.
If the way to update the system is documented in deep, there isn't much about ports. The mailing list ports-security is dormant and there is no mention about the out-of-date script.

So even if I am willing to update ports, I don't know the right way to do it.
I asked on the misc mailing list, but no answer yet...

I guess it is because OpenBSD only have a small community of developers and users which is a shame, it is a very nice project.

I ran -stable for 2 or 3 years on my production platforms. At that time, -stable packages were being built and deployed on the project's mirrors. I moved to -current around 3.8 or 3.9. I'd had a bug requiring active cooperation with a developer. Once the problem was resolved, I stayed -current on production.

Some time after my transition, the project ceased backporting -stable ports or building -stable packages, due to the workload required. Things stayed that way for several years; it is a small project with limited resources.

---

As I've stated above, "make update" is the wrong target. You may find make package (or make repackage) followed by make update will be more effective than a make update alone. The latter does not build ports, it is a package installation directive only, as is FORCE_UPDATE, per bsd.port.mk(5):

Code:

update Update an existing installation to a newer package: scan
the installation for a package with the same FULLPKGPATH,
and update it using `pkg_add -r' if a newer package is
available. In multi-packages ports, all relevant packages
are updated. See UPDATE_COOKIES_DIR and FORCE_UPDATE as
well.

This sounds a bit strange to use a security focused system and not to bother apply security patches then.

Those of us running -current get security patches the quickest

I started off using -release at home, then moved to -stable. After a bit, I ran into a bug that I discovered had already been fixed in -current, so I upgraded. Around that time I switched my Linux desktop at work for OpenBSD-current, and I never looked back.

I know it was possible to update third party applications in stable with packages in the past. But as it is not supported anymore, I guess even if some updates make their way through ports, stable is not supposed to have proper fixes for these and this is why there is no documentation about it.

It looks like you are right ! 30 answers to the poll, OpenBSD gather only few people. This is a shame, and as I said before it must be the reason why there is not enough man power to have stable updates for applications.

It looks like you are right ! 30 answers to the poll, OpenBSD gather only few people.

Again, this site is not officially affiliated with the project proper. The results of the poll are only indicative of this community at the time the poll was taken. I also would not say that the results seen here are necessarily representative of the entire OpenBSD community. Statistics like that are not maintained officially or unofficially.

Quote:

This is a shame, and as I said before it must be the reason why there is not enough man power to have stable updates for applications.

If you really want to explore discussion on the future & importance of -stable branch maintenance, search the official misc@ mailing list archives. Roughly once a year, a long protracted thread can be found on the subject.

Quote:

I guess it is safer to run current then.

It depends upon how you define the word "safer", plus you need to be very clear on the collateral responsibilities you will take upon by running -current. For starters, be very aware of what is stated in Section 5.1 of the FAQ.

As a final comment, posting your question on misc@ may not have been seen by the developers most involved in the packages/ports management. That, or given that work at this moment is focused on finalizing OpenBSD 5.0, this was not a matter of highest importance. I can only guess. Yet, if you were really interested in resolving your situation, I would suggest sending mail to espie@.

I don't think I'd dare. He might be busy and not willing answering questions like this one.

OpenBSD 5.0 (including ports...) was tagged today, so work on 5.1 is only beginning. Actually, I would think now is a very good time to be contacting espie@.

Much of what you are surmising about -stable may be correct, but contacting the project developers serves two purposes:

You might get your situation addressed.

Project developers are reminded that there are those who legitimately use -stable.

More over, there may be a third issue at bay: creating a package management system which covers a plethora of real world applications is a tough nut to crack. Maybe there is a fundamental flaw which needs to be addressed. If you pursue this further, you may get your problem resolved plus help other users. If you drop the matter & there is a bug, it will not get addressed until someone else makes the same issue known to those that can resolve the problem.

Thanks, it is much clearer now. A shame there is no option to delete the build dependencies, once the final package is created. But I guess I won't have to build them again next time I update the same packages. (well, if they don't need to be updated themselves)

-current (and I believe 5.0) have pkg_delete -a:

Code:

-a Delete unused dependencies (packages that are not needed
by anything tagged as installed manually). Can be used
without pkgnames.

__________________
Many thanks to the forum regulars who put time and effort into helping others solve their problems.