# Bit confused about current binary packages



## dpx (Jan 11, 2018)

I am probably missing something so any clarification is welcome. All I am using are current binary packages, nothing built from source.

This already happened with firefox couple of months ago but it was quickly resolved when firefox reappeared. Now I am trying to install https://www.freshports.org/emulators/i386-wine-staging/. It was available couple of weeks ago, now it is marked as "A package is not available for ports marked as: Forbidden / Broken / Ignore / Restricted" and not available.

I am confused about is why not keep previous version until new one resolves well? Are there other reasons (say incompatible new compiler or lib version) that prevents port from being always available, even if that means keeping bit older version around?

It is weird user experience not being able to rely on binary port that always exists.

Apart from building from the source (does that even work with forbidden/broken packages?) what is usual way of getting this package, even if that means older version?


----------



## Snurg (Jan 11, 2018)

i386-wine-staging is sort of testing package, like FreeBSD-Current.
There is none yet, as i386-wine-devel has been freshly updated to new version on Jan 6.
I think staging version will be created soon again, when the first patches arrive.
Use either i386-wine-devel or i386-wine.
If you want more details, see here.


----------



## dpx (Jan 11, 2018)

Thanks, I know the differences. Even old (previous) -staging build is way more advanced than current devel, they can't be compared re performance. I am just confused why previous -staging has to vanish from prebuilt packages while we wait for new patches to arrive. If there is some real reason (like old version crashing with updated current libs) then I can understand. If it is only the way that automated build process works then I think we should keep previous versions until new ones are reliably built.

From users perspective, not being able to rely that some package reliably exists all the time makes install process much less straightforward than what it can be.


----------



## SirDice (Jan 11, 2018)

Note that there are always two package repositories, quarterly; Updated once every three months, only security issues are committed. And latest packages. The latest packages are more inline with the ports tree and are constantly updated and changed.


----------



## dpx (Jan 11, 2018)

Yes, I did use quarterly up to few months ago when I switched to latest.

I don't understand the answer, can you please explain what is its relevance in relation to packages not being always available, at least in lastest?

Are they always available in quarterly? If I am using latest can I install one package from quarterly? Do I have to switch back to quarterly if I want to have them all available all the time?

Most importantly why do they occasionally vanish from latest before new package is ready to replace the old one?

I know you are telling me thing that makes sense, I just don't understand what is being told. Maybe something goes without saying and I don't know what it is. I did try to ask as simple questions as my skills allow. Help please?


----------



## rigoletto@ (Jan 11, 2018)

emulators/i386-wine-staging --> BROKEN.

Same for emulators/wine-staging.


----------



## dpx (Jan 11, 2018)

Yes, they are broken, see my first post.

There was working binary available up to a week or so ago. So question I have to repeat is why didn't binary repository keep the old binary until new one is ready?


----------



## rigoletto@ (Jan 11, 2018)

Latest means the latest ports when the entire ports tree is built. Broken ports evidently cannot be built and so there will not have packages of them in latest.


----------



## tobik@ (Jan 11, 2018)

dpx said:


> Most importantly why do they occasionally vanish from latest before new package is ready to replace the old one?


Packages are built as a whole from a single revision of the ports tree. Since the ports tree is in constant flux old packages will with a high probability not work correctly with newer packages so we cannot keep them.

Really all is done on a best-effort basis. The quarterly ports branch has less flux, so this is what you should use if you want to lessen the impact of this.


----------



## dpx (Jan 11, 2018)

tobik@ said:


> Packages are built as a whole from a single revision of the ports tree. Since the ports tree is in constant flux old packages will with a high probability not work correctly with newer packages so we cannot keep them.
> 
> Really all is done on a best-effort basis. The quarterly ports branch has less flux, so this is what you should use if you want to lessen the impact of this.



I understand the logic -- from the programmer's point of view this is the cleanest solution.

From the users point of view this is not that great, every package is Schrödinger's package, either dead or alive until you try installing it. Would it make sense for latest binary repository to either keep previous binary package until new one becomes available (if it is lib compatible with latest libs) or at least rebuild the package with the latest known good state (source/make), linking the new libs? Either of those two options would guarantee package availability in all times.

Having any package potentially not available is best and cleanest from one point of view but really sub-optimal user experience from the other.


----------



## Eric A. Borisch (Jan 11, 2018)

Create /usr/local/etc/pkg/repos/fallback.conf:

`FreeBSD: { priority: 1 }

Fallback: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/release_0",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes,
  priority: 0
}`

This (/release_0) has a snapshot of the pkgs that were available (and building) when the .0 release (11.0, for example) was cut. /release_N is also available up to the latest minor version.

I'm not suggesting it for general use, but I think this will do what you want. (Use FreeBSD (main) repo if a package/update is available there, "Fallback" to the v.0 snapshot if it is not.) You should also be able to configure it as `enabled: no` and select it with `pkg install --repository=Fallback pkg_name` when needed.

This is not quite what you asked for, but it gives you some fallback.


----------



## dpx (Jan 11, 2018)

That's great advice Eric, thanks. Exactly what I needed -- I just knew there has to be the way to reach 'outdated' packages but didn't know how.

Edit: Yes, not really 'last package that built well' but more than good enough to patch something while we wait for actual latest build.


----------



## dpx (Jan 11, 2018)

Oh I would really hesitate to recommend this to anybody but having main repo at pkg+http://pkg.FreeBSD.org/${ABI}/latest with priority 1 and fallback at pkg+http://pkg.FreeBSD.org/${ABI}/quarterly with priority 0 is a beauty.

Yeah I can have problems and may burn in hell but I can install wine-staging and as soon as it is available in main repo it will update as it should. Thanks Eric!


----------



## rigoletto@ (Jan 11, 2018)

Alternatively, if you still have the old package in cache, you can install that again and use `pkg lock`.


----------



## Eric A. Borisch (Jan 11, 2018)

dpx said:


> That's great advice Eric, thanks. Exactly what I needed -- I just knew there has to be the way to reach 'outdated' packages but didn't know how.
> 
> Edit: Yes, not really 'last package that built well' but more than good enough to patch something while we wait for actual latest build.



Yes, _DON'T DO THIS_, unless you _really_ need to, and you _*understand*_ why you're doing it.


----------



## dpx (Jan 11, 2018)

Agreed, it is good enough for my own needs but I would really hesitate to tell somebody else how to use it -- imagine all the mess to explain what went wrong if anything goes wrong


----------

