pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64

Having the name of the dist file in the Makefile is useful. That at least allows you to retrieve it manually.
The only reason I spoke up is because I spent the legwork chasing old ports and it is not reliable.
Creaky would be the adjective I use. Not because of FreeBSD ports, but the fluidity of file hostings on the internet.
 
cy@ said:
Let's say for example a person is running FreeBSD 8.1 (I know of a company, not mine, still running this version of FreeBSD and an old employer of mine was running 4.4.0 until recently). Let's say they want to install a port. They could,

git clone https://github.../ports.git
git checkout release/8.1.0 or git checkout release/4.4.0

With this they have the ports collection as of the day 8.1.0 was released. Just cd to the port and make install.

Anticipating someone saying, "but how do I git clone without git on the box?" Easy. Find a system that has git, Linux, FreeBSD or whatever, then ./configure and make. It's not hard to do.

Anticipating: "but that's too hard." Easy. Doing builds by hand, using ftp or schlepping files over the network should be easy for any sysadmin. When I switched careers from IBM mainframe to UNIX in 1992, all we had was ./configure, if even that. We made it work. When running old unmaintained software, these re the things a person needs to do.

As for maintaining an old EOL system, a system that will never receive security updates again on one's network. How's that secure? Think about that for a while.

As for maintaining old versions of packages for releases that are EOLed just in case some random person might want some random package years down the road is ridiculous. Think about that a little.
Click to expand...
Thanks. So will this get me the source code to the O.S. or also to all the latest version of all the packages for optional software for that O.S. release? How do I build a package file on a development system to then copy over to the deployment system and use "pkg" to install it? Make install will install things on my development system but will not give me a package I can copy over to the deployment system and use the installer to install there (or indeed even just a tarball which isn't ideal anyway as it doesn't warn me about missing dependencies). It will also not build all the dependencies but I guess pkg will tell me about the missing dependencies once I try to install the package and I can build those, rinse and repeat.

If you want to understand why upgrading the O.S. is not an option in my - and many other peoples' - circumstances - great. If not, that's your prerogative. I'm not trying to change your mind. I'm just trying to solve a problem. If you have something constructive to add to that end, thank you. I will not use FreeBSD on new installs, because FreeBSD policy on deleting packages for EOL systems does not work for me. In the meantime, I do have to maintain my existing installations.
 
tomaz said:
How do I build a package file on a development system to then copy over to the deployment system and use "pkg" to install it?
Click to expand...
Anything before 9.0 won't support pkg(8) aka PKGNG. Those versions used the 'old' pkg_tools.

tomaz said:
Make install will install things on my development system but will not give me a package
Click to expand...
make package has existed since the dawn of time, or FreeBSD 3.0 in my case.
tomaz said:
It will also not build all the dependencies but I guess pkg will tell me about the missing dependencies once I try to install the package and I can build those, rinse and repeat.
Click to expand...
There's also make package-recursive, which does what you would expect.

tomaz said:
I will not use FreeBSD on new installs, because FreeBSD policy on deleting packages for EOL systems does not work for me. In the meantime, I do have to maintain my existing installations.
Click to expand...
I don't understand why you aren't storing those files yourself, if they're that important to you. Why are you relying on third parties to keep providing them?
 
SirDice said:
Anything before 9.0 won't support pkg(8) aka PKGNG.


make package has existing since the dawn of time.
Click to expand...
Before there was pkgng we had pkg, as in pkg_info, pkg_install, etc. Ports needed to be installed into /usr/local, then make package would create a tarball containing all the files in pkg-plist + install scripts + the plist itself. Packages were staged on a real live FreeBSD system on infrastructure called Bento. There was a site called redports that assisted developers with package testing. I assume they had real computers (for jail was still a gleam in someone's eye).

Tools such as portmaster and portupgrade (both are still in ports) would automate this process for you.

Back in those days I'd build by hand on one of my machines and rsync /usr/local /var/db/{ports,pkg} to the various machines in my network.

The ports infrastructure was quite fragile at the and took a lot of hand holding.

So yes, a person could do this the "old way"(tm). But why? Why run old software?

During my 40+ year career on mainframe, UNIX, FreeBSD, Linux, etc. Those who choose not to upgrade or not to patch are afraid their app will break. Many of my clients over the years have felt that way. Only to panic when the situation forced them to abandon their lazy ways because of some urgent need -- usually a serious event of some kind that required them to react instead of adopting proactive habits.

Case in point. One client refused to approve O/S patching and failed to perform any application maintenance. That all changed due to meltdown. Painful lesson learned.

One can choose to sleep at night or choose a life of pain. Like everything. It's a choice.
 
SirDice said:
Anything before 9.0 won't support pkg(8) aka PKGNG. Those versions used the 'old' pkg_tools.


make package has existed since the dawn of time, or FreeBSD 3.0 in my case.

There's also make package-recursive, which does what you would expect.


I don't understand why you aren't storing those files yourself, if they're that important to you. Why are you relying on third parties to keep providing them?
Click to expand...
Thanks, I'll try make package-recursive.

I don't maintain full repositories of all the packages for all the versions of all the operating systems I have installed on all my systems, and keep them up-to-date. I don't know anyone who does that.

I don't think most O.S. distros delete package repositories for old O.S. versions, at least I've never come across this problem before.

But you're right, perhaps I should review which repositories of which O.S.'s are most critically important to me and mirror at least a version of them, in case some catastrophe happens and the entire Internet goes offline, etc.
 
cy@ said:
Why run old software?

During my 40+ year career on mainframe, UNIX, FreeBSD, Linux, etc. Those who choose not to upgrade or not to patch are afraid their app will break.
Click to expand...
Because it works.

Because sometimes you don't have a choice.

Because sometimes you just don't want to. Maybe the new version has some "features" you don't want on your computer. Maybe it contains spyware. Maybe it doesn't but you can't verify that. Maybe you've spent 3 years working around all the bugs in the old O.S. version and now things just about work, and you don't want to spend the next 3 years working around the bugs in the new O.S. version. And maybe you just don't want to - just because.

In my >40 years of using mainframes, Unix, FreeBSD, Linux, etc. I've found that the concerns of those who fear their app will break are often well justified.

As I said, each to his own. I'm not going to try to change your mind. I'm just trying to solve a problem.
 
tomaz said:
Because it works.
[...]
[...]
Click to expand...
So, lots of words with not a single real answer. Well then, I guess we know what the answer is. Yes, fear is one component of it, I'll leave the others to the readers' conclusion...

A system (or even just software) past EoL with a network connection is a ticking timebomb. That's what you should fear, not software upgrades.

It really amazes me there are people who obvioulsy believe to do professional work and then come up with "I can't upgrade this system".

I'm used working at a larger scale company. It happens some system gets past EoL. It creates a lot of drama when it happens, which could very quickly escalate up to the CISO. And this really is how it should be. There's absolutely nothing that could ever justify the risk of running unpatched old software.
 
zirias@ said:
mer said:
I have a Windows 3.3 system but I can't find any application updates to run on it.
Click to expand...
Click to expand...
Much of this thread has been dominated by people like Beavis preaching to those trying to solve real world problems, delivering haughty sermons about what should and ought to be, in theory, while simultaneously demonstrating a comprehensive lack of knowledge or understanding of the real world or its constraints, or any respect for other people who have to deal with the said practical real world constraints. Is this another example of the same or do you know something the rest of us don't? I've never heard of Windows 3.3. There was 3.2 and 3.5 but AFAIK, there was no 3.3.

In theory, you're running a Windows 3.3 and can't find any application updates to run on it. In practice, you're speaking without having tested your theory in practice (or you'd know it doesn't work), you're talking in theory and those of us who do know the practice know that your "in theory" doesn't work in practice. It's a trivial point, but a pretty good illustration of what's wrong with many of the more arrogant responses in this thread.
 
tomaz said:
Much of this thread has been dominated by people like Beavis preaching to those trying to solve real world problems, delivering haughty sermons about what should and ought to be...
Click to expand...
Keep whining. It's bound to work eventually.
 
tomaz said:
Because it works.

Because sometimes you don't have a choice.

Because sometimes you just don't want to. Maybe the new version has some "features" you don't want on your computer. Maybe it contains spyware. Maybe it doesn't but you can't verify that. Maybe you've spent 3 years working around all the bugs in the old O.S. version and now things just about work, and you don't want to spend the next 3 years working around the bugs in the new O.S. version. And maybe you just don't want to - just because.

In my >40 years of using mainframes, Unix, FreeBSD, Linux, etc. I've found that the concerns of those who fear their app will break are often well justified.

As I said, each to his own. I'm not going to try to change your mind. I'm just trying to solve a problem.
Click to expand...
That's what those clients, said. Especially one of clients that got pwned. Their strategy to not update software resulted in a lot more pain than they had bargained for.

I told them two weeks before they got pwned what needed to be done (in this case a $50K firewall, O/S patching, and application patching and maintenance). They replied this would cost too many $$$. They didn't want to put the work in nor did they want to spend the $$$. Oh I get it alright. It's all about the work that might not need to be done and the $$$ that might be saved. When all was set and done they spent $50M on remediation from being pwned when in fact a few $ spent proactively on a firewall, O/S patching and application maintenance would have saved millions.

But as you said, "each to his own."

This attitude keeps people like me gainfully employed.
 
cy@ said:
That's what those clients, said. Especially one of clients that got pwned. Their strategy to not update software resulted in a lot more pain than they had bargained for.

I told them two weeks before they got pwned what needed to be done (in this case a $50K firewall, O/S patching, and application patching and maintenance). They replied this would cost too many $$$. They didn't want to put the work in nor did they want to spend the $$$. Oh I get it alright. It's all about the work that might not need to be done and the $$$ that might be saved. When all was set and done they spent $50M on remediation from being pwned when in fact a few $ spent proactively on a firewall, O/S patching and application maintenance would have saved millions.

But as you said, "each to his own."

This attitude keeps people like me gainfully employed.
Click to expand...
I'm glad your way works for you. My way works for me too. I've never had a security breach in ~45 years so I think I'll keep doing what I'm doing, thank you. Even if I, unlike our friend Beavis, don't already know everything and don't have nothing to learn from anyone else.

Your story is all very interesting but not very relevant to my situation where upgrading the operating system of this appliance is *not*possible*. It is also not necessary. It would add nothing to the security of my setup, and quite possibly could detract from it.

For the record, in my experience, performing regular software updates (= having a perpetually unstable software setup & not knowing what new bugs and security gaps and possibly even deliberate malware are constantly being introduced) is an extremely poor security practice. Unless you audit and secure your installation anew every time you update the software, which is far too much work to be practical, and even then constantly changing your software makes it much more likely you'll miss something at least once. It's much less risky to freeze your software installation - after you've made sure it is properly secured - and then leave it unchanged.

At any rate, my thanks to SirDice for his make package-recursive tip, I'll try it out if and when I have some spare time to install a development system.
 
tomaz said:
For the record, in my experience, performing regular software updates (= having a perpetually unstable software setup & not knowing what new bugs and security gaps and possibly even deliberate malware are constantly being introduced) is an extremely poor security practice.
Click to expand...

This is such nonsense, I have no words...
 
Respecting minor version updates:
zirias@ said:
But JUST WHY are there always people insisting on running EOL systems? What's the deal? It's not like upgrading hurts or something. Especially talking about *minor* versions.
Click to expand...
The recent update to Firefox-102esr introduced two minor inconveniences:

1. There is no sound when streaming a/v files.
2. Opening a new tab cases the tab to crash in the majority of cases.

So much for painless minor updates. And, just to make sure the pain cannot go away the dependency tree for Firefox changed from atk to at-spi2-core. So there is no going back either. The cause of the tab crashes seems to be a bug relating to the builtin auto-updater feature being disabled in the FreeBSD port. The sound issue has a separate cause. Both are reported on bugzilla. Upstream is not going to fix the crash issue in 102esr. The sound issue may or may not get solved.
 
As the OP I can state with assurance that the context of this thread is the availability of packages for EOL versions, NOT FreeBSD itself. The statements made about the 'ease' and 'painlessness' of 'minor' upgrades simply talk past the issue and pretend that it is something else entirely.

zirias@ said:
What's done in third-party software isn't under FreeBSD's control
Click to expand...
What software gets released in ports and packages IS under FreeBSD's control. The bug in Firefox-esr 102 was reported to upstream several months ago and was released to the unsuspecting FreeBSD user community in April. At that time 102esr was known to be broken and it was known that upstream was not going to fix it. So, why was it released? Why was it not simply skipped? Let me guess: security. Well, if one wants to prevent car theft then destroying the car is one way of securing it.

Note that the OS is up-to-date and supported. It just that the software released through official channels simply does not work properly. That that application was built in such a way as to make impossible the re-installation of the older, working, version is just icing on the cake. FF112 has fixed the tab crash issue. But, that is small comfort for those of us who needsbe work with the esr version.

And a/v sound is still missing from 112.

This message is simply to point out the utter fallacy of the idea that minor updates are without risk and negative consequences.
 
Y'know, if you know git, and how to build packages, OP, you can check out the ports tree, set it to the correct version, and compile the packages yourself.

That's the price for sticking to old stuff that nobody else wants to bother with any more.

This is a forum of DIY'ers... you're bound to run into someone doing the same kind of thing, out of necessity - or for fun.

Share information, experiences, etc - that's what these Forums are for.
 
The problem with that solution is that this 'minor' update changed the dependency tree for 102esr. The earlier esr version requires atk. Well, atk is gone and to reinstall it requires unloading most, if not all, of the last quarterly update.
 
zirias@ said:
No, that's just shifting the goalpost. I won't bother any more...
Click to expand...
Restating the original issue is not shifting the goalpost. It simply brings the discussion back to the central question, the availablity of working packages regardless of the OS version.
 
You must log in or register to reply here.
Back
Top