GNOME Software 3.14 Will Work On Arch Linux With PackageKit

[souenzzo]

One more time...
pacman -Sy is not a feature of pacman. It's a feature of pacman user.
If you know what you doing, you CAN make pacman -Sy with no problems..

[SciK]

One more time...
pacman -Sy is not a feature of pacman. It's a feature of pacman user.
If you know what you doing, you CAN make pacman -Sy with no problems..

But very rarely should you, if ever.

pacman -Syu package isn’t much longer, to type or to run. (And anyway, the longer it takes in comparison, the more dangerous pacman -Sy would have been.)

[pjezek]

Not worth for archers

I use Arch ten years and have no complaints to pacman/yaourt functions instead of fresh look on installed/available. That's why Octopi exist, indeed. PackageKit for Arch is for those depending on pure GUI utilities and huge DEs with own package management frontends. No such a way is an Arch way and a logical way... I can get ALL Gnome or KDE packages including DE-specific ones by pacman itself if I want - but I really don't...

[Sonadow]

Since we are talking about Arch, can anyone answer some of my questions?

As is the case with most non-rolling release distributions, the repositories are typically locked to specific versions of libraries, system applications, etc for the lifespan of the particular release. And this can be further locked to allow only release-time packages by disabling the updates repository. Which is what I do with any distribution installed in my computers.

In Arch, the repositories are always updated daily, which introduces a huge degree of instability (instability as in the repositories are always in a state of flux). Is it possible to lock the Arch repositories to, say only use packages available in the repository only on X / XX / XXXX? Example being, I install Arch today, and i want to have the repositories locked to this particular day for the next 3 years until I'm ready to unlock them and do a full system upgrade to the latest kernel / xorg / etc etc, then lock the repos again to the day the upgrade was carried out for the next 3 years, and so on.

Or will using a typical release-type distribution be more useful for my needs? Im just too lazy to have to reinstall the operating system every 2 -3 years and recompiling my favorite software all over again.

[Ericg]

Since we are talking about Arch, can anyone answer some of my questions?

As is the case with most non-rolling release distributions, the repositories are typically locked to specific versions of libraries, system applications, etc for the lifespan of the particular release. And this can be further locked to allow only release-time packages by disabling the updates repository. Which is what I do with any distribution installed in my computers.

In Arch, the repositories are always updated daily, which introduces a huge degree of instability (instability as in the repositories are always in a state of flux). Is it possible to lock the Arch repositories to, say only use packages available in the repository only on X / XX / XXXX? Example being, I install Arch today, and i want to have the repositories locked to this particular day for the next 3 years until I'm ready to unlock them and do a full system upgrade to the latest kernel / xorg / etc etc, then lock the repos again to the day the upgrade was carried out for the next 3 years, and so on.

Or will using a typical release-type distribution be more useful for my needs? Im just too lazy to have to reinstall the operating system every 2 -3 years and recompiling my favorite software all over again.

I don't think any distro really "locks" packages.. The only difference being is if they separate out "Fedora" and "Fedora-Updates" or the likes. On Arch especially I don't think they keep around too many versions of packages, so if you did want to do something like that you'd have to make a mirror of -every- package then strip out all your repos and point only at the mirror you made.

Even if you DID manage to do that, I don't think that long of updates are supported by Arch, or any distro thats not "Enterprise" grade, anyway.

Really what you're looking for is CentOS (And even then you'll get Kernel, Mesa, Xorg, etc updates through 7.x versions) or Debian Stable.. though why you'd want to do any of what youre talking about is beyond me from a security and bug perspective. (When you say you want to lock them im assuming you aren't letting in bug fix releases or security updates and are really sitting on the exact same versions, without updates of any kind, for 2-3years)

[Sonadow]

When you say you want to lock them im assuming you aren't letting in bug fix releases or security updates and are really sitting on the exact same versions, without updates of any kind, for 2-3years

Spot-on.

I'm still using Mageia 2 and OpenSUSE 12.2 to date. Both are close to two years old, and the only packages that they are pulling in from the repos are those that were made available on the day they were released; updates repos disabled. It's the stability i want.

And CentOS / Debian Stable are not options. They ship with outdated packages on release day. It's not uncommon for a fresh CentOS and Debian release to have system libraries incapable of building the latest version of Chromium, or system packages like Mesa too old to support the latest hardware and GPUs, on release day.

[Sonadow]

Spot-on.

I'm still using Mageia 2 and OpenSUSE 12.2 to date. Both are close to two years old, and the only packages that they are pulling in from the repos are those that were made available on the day they were released; updates repos disabled. It's the stability i want.

And CentOS / Debian Stable are not options. They ship with outdated packages on release day. It's not uncommon for a fresh CentOS and Debian release to have system libraries incapable of building the latest version of Chromium, or system packages like Mesa too old to support the latest hardware and GPUs, on release day.

That also means that Debian Sid and Debian Testing aren't options, because their repositories are constantly being updated. Unless I grab an image of Testing as soon as it enters the package freeze period. Because i typically want to have the latest packages at the time of installation so that they can last for 2 -3 years without getting obsoleted. Google's software such as Chromium and Web Designer are known to obsolete packages very quickly.

[Ericg]

Spot-on.

I'm still using Mageia 2 and OpenSUSE 12.2 to date. Both are close to two years old, and the only packages that they are pulling in from the repos are those that were made available on the day they were released; updates repos disabled. It's the stability i want.

And CentOS / Debian Stable are not options. They ship with outdated packages on release day. It's not uncommon for a fresh CentOS and Debian release to have system libraries incapable of building the latest version of Chromium, or system packages like Mesa too old to support the latest hardware and GPUs, on release day.

Ubuntu LTS? Mint Debian? (Rolling release but with monthly updates) I really don't think you're gonna get 2-3yrs of stability without hitting the "CentOS" or "Debian" teams. Really not trying to be an ass but I think the best summary is "your usecase is not supported."

You can use Fedora stable and just not update but then you only get a year until you have to fedup. You can use Fedora rawhide but you have a high chance of existing bugs and the likes. (Either of those options run into the problem of "updates after that long aren't supported" )

[Sonadow]

You can use Fedora stable and just not update but then you only get a year until you have to fedup.

That was actually my modus operandi for a while; use the latest version of Fedora with its bleeding edge packages, disable the updates repo and milk the heck out of the release-date packages for 2 - 3 years, then perform a clean install of a new Fedora release when I'm ready to upgrade. Rinse and repeat.

That is, until the mirrors became rather enthusiastic in taking down the repositories for EOL-ed releases. As of now i'd be very lucky if an old Fedora release's repositories will still be up after 2 years.

[Ericg]

That was actually my modus operandi for a while; use the latest version of Fedora with its bleeding edge packages, disable the updates repo and milk the heck out of the release-date packages for 2 - 3 years, then perform a clean install of a new Fedora release when I'm ready to upgrade. Rinse and repeat.

That is, until the mirrors became rather enthusiastic in taking down the repositories for EOL-ed releases. As of now i'd be very lucky if an old Fedora release's repositories will still be up after 2 years.

I really don't think there's any distro that caters to you Sonadow... that's one of the more bizarre use cases I've ever heard of to be perfectly blunt, and your best bet is enterprise grade (which you shot down), checking out freebsd, running your own package mirrors, or creating your own distro