could mixing packages and ports problematize system integrity in this case ?

[daemonfowl]

Hi everybody !

Could mixing packages and ports problematize system intergrity/stability when upgrading the OS and a few packages while still keeping compiled ports comparatively older (ie, ports tree) ?
(Please correct me if my question is *false* or ill-founded or .... )

[ocicat]

Originally Posted by daemonfowl

Could mixing packages and ports problematize system intergrity/stability when upgrading the OS and a few packages while still keeping compiled ports comparatively older (ie, ports tree) ?

What does Section 15 of the FAQ say about the differences between ports & packages?

[daemonfowl]

I guess I was missing the anoncvs faq
Now the view is less smoggier .. truly the FAQ are the best healer.

[ocicat]

Originally Posted by daemonfowl

I guess I was missing the anoncvs faq
Now the view is less smoggier .. truly the FAQ are the best healer.

I don't know what this response says, nor do I understand what relevance it has on the original question.

[daemonfowl]

I mean after all , the more I miss , the more I ask wrong questions ..
I was thinking what to do with those *compiled packages* and how to upgrade them etc when I upgrade then update all *packages* .. have you ever seen an incarnation of foolishness ? well it's me ..

[ocicat]

Originally Posted by daemonfowl

what to do with those *compiled packages* and how to upgrade them etc...

Okay, you're going to get the same answer as before. What does Section 15 of the FAQ say about upgrading packages?

[daemonfowl]

that I can update packages with pkg_add -u ..
yet aren't compiled packages different in that unless I upgrade the ports tree with cvs , packages built by the ports system remain untouched ..... or is this another silly point of mine?

[ocicat]

Originally Posted by daemonfowl

I can update packages with pkg_add -u ..

Correct. pkg_add -u will update packages if newer packages are available on PKG_PATH. It does not matter whether the currently installed packages come from a mirror site or were compiled locally.

Look at the contents of the package system database in /var/db/pkg. You will find version information & dependency information. You will not find information as to where the package came from being tracked.

What pkg_add -u will do is update packages depending upon whether a newer version is found on PKG_PATH. Yes, this may mean that a package installed from a locally installed port may get replaced with a newer package found on a mirror.

or is this another silly point of mine?

Somehow you are wanting to make locally compiled ports somehow different. They aren't. The result of building ports are packages -- the very same packages which are available on the mirrors.

Whether your point is silly is immaterial. What is more of concern is where you come up with these incorrect ideas. You can help yourself by confirming your knowledge through study of the documentation. Developing the discipline to read & study before posting will help you grow technically. Simply coming to this site & posting questions which you have thought about for less than five minutes only makes you dependent upon whatever we impart to you. This kind of dependency is never going to get you very far. Ever.

[daemonfowl]

Thanks for clearifying points and sorry if I'm too dumb to ask again :
Are the once compiled opera & httrack -for instance- gonna be upgraded too, following a pkg_add -u charm ?
* opera : being part of the ports tree
* httrack : not being part of the ports tree
Or will there be no difference the time when httrack is hosted in /usr/ports/www and compiled as it becomes a member and so can be upgraded as well ?
( Anyway, I can see that Opera dwells in /var/db/pkg .. whereas httrack doesn't and both were compiled and I can use both.. )

[jggimi]

1. The ports tree builds packages.
2. You have manually built and installed "httrack". Therefore, "httrack" is not a package and will not be affected by any of the package tools.
3. If, in the future, "httrack" is added to the ports tree, your personal version of "httrack" will not be affected.
4. If, in that future, you attempt to install an "httrack" package, the pkg_add will likely fail due to collisions with your pre-existing files from your custom, outside-the-tree build and install of "httrack".
5. In that future, you would have to manually de-install your custom "httrack" from your OpenBSD system in order to install this future "httrack" package.