Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] Alternatives to gentoo that solve these problems?
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
crocket
Apprentice
Apprentice


Joined: 29 Apr 2017
Posts: 213

PostPosted: Wed Feb 28, 2018 11:55 pm    Post subject: [SOLVED] Alternatives to gentoo that solve these problems? Reply with quote

I moved from ArchLinux to Gentoo because systemd and AUR were frustrating me with various issues.
I liked the fact that Gentoo treats third party, local, and official repositories seamlessly.
However, gentoo has a few issues.


  • libreoffice-bin breaks often. Often, I cannot upgrade my system, or libreoffice-bin has its libraries broken after upgrade. I don't want to compile libreoffice on a slow laptop although I compile libreoffice on my fast desktop.
  • I use several haskell packages from haskell overlay. Due to https://bugs.gentoo.org/555266, haskell overlay maintainer cannot prevent his haskell packages from breaking often. I often cannot upgrade because haskell overlay packages are often broken.
  • emerge alone cannot upgrade haskell packages. Thus, I need to alternate between emerge and haskell-updater to upgrade haskell packages. This is bad. Sometimes, I need to alternate among haskell-updater, perl-updater, and emerge to upgrade my system. Why is emerge alone not sufficient for system upgrade?


I considered Void Linux, but it doesn't support third party and local repositories as Gentoo does.
I've used Artix Linux on my slow laptop, but it often breaks packages because it hasn't fully ported packages from ArchLinux to Artix Linux.

What alternative OSes do you recommend? I want


  • Rolling release
  • Independence from systemd (and pulseaudio). Ideally, I want to avoid dbus, too, but I couldn't avoid it on any OS I've used so far.
  • Ease of managing third party and local repositories
  • Stability of binary packages in official repository
  • Stability of third party repositories. I mean issues like https://bugs.gentoo.org/555266
  • Smooth upgrade without errors (I don't want to use haskell-updater and perl-updater because emerge fails with errors during upgrade.)


Last edited by crocket on Fri Mar 02, 2018 10:31 am; edited 1 time in total
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 7090
Location: Saint Amant, Acadiana

PostPosted: Thu Mar 01, 2018 12:35 am    Post subject: Reply with quote

https://www.linuxquestions.org/questions/linux-general-1/i-like-gentoo-but-it-has-several-issues-that-make-me-want-to-try-other-oses-4175624625/

Sure, there happens to be a discussion going on, what a coincidence.
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
crocket
Apprentice
Apprentice


Joined: 29 Apr 2017
Posts: 213

PostPosted: Thu Mar 01, 2018 12:50 am    Post subject: Reply with quote

Jaglover wrote:
https://www.linuxquestions.org/questions/linux-general-1/i-like-gentoo-but-it-has-several-issues-that-make-me-want-to-try-other-oses-4175624625/

Sure, there happens to be a discussion going on, what a coincidence.


That's me. Because linuxquestions.org seems to be biased toward slackware, I wanted to hear from gentoo users' perspectives.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13842

PostPosted: Thu Mar 01, 2018 2:34 am    Post subject: Reply with quote

Prebuilt (*-bin) packages break when they depend on libraries that change ABIs. This is unavoidable. The only possible fixes are to rebuild the package (meaning, not use a prebuilt or wait for the prebuilt maintainer to recompile the package and upload a new version) or to cease breaking the underlying ABI. Linux has facilities for clean shared library upgrades, but some projects persist in not using them, leading to more ABI breaks than are needed.

In what way do the Haskell packages break? The linked bug report requests an extension to repoman, which seems useless here. First, I can't find anything that explains why the Haskell maintainers use upper-bound versions. The bug links to https://wiki.haskell.org/Package_versioning_policy which, after some silly redirects, leads to a page that says only that this is the standard, but fails to explain why:
https://wiki.haskell.org/Package_versioning_policy wrote:
When publishing a Cabal package, you SHALL ensure that your dependencies in the build-depends field are accurate. This means specifying not only lower bounds, but also upper bounds on every dependency.
This looks simply broken to me. The only reason I can guess for this is that dependent packages are so bad about breaking their ABI that forcing maintainers to constantly update dependency whitelists is seen as less trouble than expecting new versions of packages to be backward compatible. If Gentoo did that on a wide scale, it would need a lot more maintainers to handle all that busywork.

Second, even if it were useful, it is still pointless, because it would only be a semi-automated way for the Haskell maintainer to discover after the fact that it's time to update the whitelists again. It does nothing to address the fact that the whitelists would need to be updated, committed, and published. Nor does it provide any help actually validating that the new versions are safe to whitelist. If the maintainer intends to whitelist without validating, then why maintain a whitelist at all? If he does intend to validate before whitelisting, then he will doubtless spend far more trouble performing validations than he can save through the repoman extension.

Although perl upgrades are a bit rough without support for slots on dev-lang/perl, I have not needed perl-cleaner (there appears to be no perl-updater) in quite a while. I don't use Haskell packages. Could you describe the failures where emerge alone was insufficient?
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7071

PostPosted: Thu Mar 01, 2018 3:01 am    Post subject: Re: Are there alternatives to gentoo that solve these proble Reply with quote

crocket wrote:
I don't want to compile libreoffice on a slow laptop although I compile libreoffice on my fast desktop.

Then just make the fast desktop build a binary out of it for the slow laptop.
Back to top
View user's profile Send private message
crocket
Apprentice
Apprentice


Joined: 29 Apr 2017
Posts: 213

PostPosted: Thu Mar 01, 2018 3:15 am    Post subject: Reply with quote

Hu wrote:
Prebuilt (*-bin) packages break when they depend on libraries that change ABIs. This is unavoidable. The only possible fixes are to rebuild the package (meaning, not use a prebuilt or wait for the prebuilt maintainer to recompile the package and upload a new version) or to cease breaking the underlying ABI. Linux has facilities for clean shared library upgrades, but some projects persist in not using them, leading to more ABI breaks than are needed.

In what way do the Haskell packages break? The linked bug report requests an extension to repoman, which seems useless here. First, I can't find anything that explains why the Haskell maintainers use upper-bound versions. The bug links to https://wiki.haskell.org/Package_versioning_policy which, after some silly redirects, leads to a page that says only that this is the standard, but fails to explain why:
https://wiki.haskell.org/Package_versioning_policy wrote:
When publishing a Cabal package, you SHALL ensure that your dependencies in the build-depends field are accurate. This means specifying not only lower bounds, but also upper bounds on every dependency.
This looks simply broken to me. The only reason I can guess for this is that dependent packages are so bad about breaking their ABI that forcing maintainers to constantly update dependency whitelists is seen as less trouble than expecting new versions of packages to be backward compatible. If Gentoo did that on a wide scale, it would need a lot more maintainers to handle all that busywork.

Second, even if it were useful, it is still pointless, because it would only be a semi-automated way for the Haskell maintainer to discover after the fact that it's time to update the whitelists again. It does nothing to address the fact that the whitelists would need to be updated, committed, and published. Nor does it provide any help actually validating that the new versions are safe to whitelist. If the maintainer intends to whitelist without validating, then why maintain a whitelist at all? If he does intend to validate before whitelisting, then he will doubtless spend far more trouble performing validations than he can save through the repoman extension.

Although perl upgrades are a bit rough without support for slots on dev-lang/perl, I have not needed perl-cleaner (there appears to be no perl-updater) in quite a while. I don't use Haskell packages. Could you describe the failures where emerge alone was insufficient?


Specifically, https://github.com/gentoo-haskell/gentoo-haskell/issues/669

Whether or not upper bounds for haskell packages are silly, it is a standard in haskell world. I have no control over that. On the other hand, I have no control over how gentoo developers handle things.
Perhaps, you need to talk with haskell overlay maintainer about this issue. I am not the best person to talk about it with.

Also, haskell-updater and perl-cleaner shouldn't be needed. Is there a way to obviate haskell-updater and perl-cleaner?
Back to top
View user's profile Send private message
crocket
Apprentice
Apprentice


Joined: 29 Apr 2017
Posts: 213

PostPosted: Thu Mar 01, 2018 3:34 am    Post subject: Re: Are there alternatives to gentoo that solve these proble Reply with quote

krinn wrote:
crocket wrote:
I don't want to compile libreoffice on a slow laptop although I compile libreoffice on my fast desktop.

Then just make the fast desktop build a binary out of it for the slow laptop.


That's a way although making my laptop rely on my desktop feels suboptimal.
I'm also considering installing Void Linux on my laptop because my laptop doesn't need many packages or package customizations.


Last edited by crocket on Thu Mar 01, 2018 5:18 am; edited 1 time in total
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13842

PostPosted: Thu Mar 01, 2018 4:56 am    Post subject: Reply with quote

That issue looks like just a recounting of the negative consequences of the upper bound dependencies. I stand by my earlier claim. The only even vaguely valid reason I can see for systematically applying upper bound dependencies is if you have a high degree of confidence that new versions will usually break everything, such that maintaining exhaustive whitelists is less trouble than dealing with the inevitable breakage.

If the Haskell packages cannot or will not use sane packaging practices, you should probably not rely on them.

I still don't know why you need the cleaners at all, so I cannot comment on how not to use them. I have not needed them in quite a while.
Back to top
View user's profile Send private message
crocket
Apprentice
Apprentice


Joined: 29 Apr 2017
Posts: 213

PostPosted: Thu Mar 01, 2018 5:20 am    Post subject: Reply with quote

Hu wrote:
That issue looks like just a recounting of the negative consequences of the upper bound dependencies. I stand by my earlier claim. The only even vaguely valid reason I can see for systematically applying upper bound dependencies is if you have a high degree of confidence that new versions will usually break everything, such that maintaining exhaustive whitelists is less trouble than dealing with the inevitable breakage.

If the Haskell packages cannot or will not use sane packaging practices, you should probably not rely on them.

I still don't know why you need the cleaners at all, so I cannot comment on how not to use them. I have not needed them in quite a while.


Emerge fails during upgrade. When emerge fails, it tells me to use 'haskell-updater'. So, I use it. I use haskell-updater once per week or once per two weeks.

I don't want to avoid using hledger just because of packaging issues. Despite issues, haskell overlay is the easiest way to manage hledger, stack, and other haskell packages on Gentoo.

I think https://bugs.gentoo.org/555266 is the best gentoo developers can do because both gentoo and haskell can't change their package management system.
I don't care about how silly upper bounds are, but I want smooth upgrades as a user.
With automated warnings from repoman or some other software, haskell overlay maintainer can avoid breaking haskell packages every week.


Last edited by crocket on Thu Mar 01, 2018 5:41 am; edited 1 time in total
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2574

PostPosted: Thu Mar 01, 2018 5:40 am    Post subject: Reply with quote

Sparknotes:

a) use the desktop to build a binary. The solution is in the portage man pages, so the details are left as an exercise to the reader

b) Royal. Pain. In. The... Rear. If you must use Haskell packages from the overlay, stop syncing it so often. If it ant broke don't fix it.

This seems to be a theme with Haskell which explains why it hasn't caught on despite being a very interesting language.

c) See above. Stop trying to update something that isn't broken. Or at least update the main tree first then sync the overlays for an upgrade. The problem with overlay software is that it may be poor quality or good quality. You don't know until you try it.

Quote:
Independence from systemd
Sorry kid. You get Gentoo, Slackware, or a close relative thereof. The Daleks have taken over everything else.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10261
Location: Somewhere over Atlanta, Georgia

PostPosted: Thu Mar 01, 2018 10:31 am    Post subject: Reply with quote

The Doctor wrote:
Sorry kid. You get Gentoo, Slackware, or a close relative thereof. The Daleks have taken over everything else.
I wouldn't count Devuan out just yet. (Not that it solves any other of crocket's stated problems, but it's init system agnostic.)

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2273
Location: Bardowick, Germany

PostPosted: Thu Mar 01, 2018 12:51 pm    Post subject: Reply with quote

John R. Graham wrote:
The Doctor wrote:
Sorry kid. You get Gentoo, Slackware, or a close relative thereof. The Daleks have taken over everything else.
I wouldn't count Devuan out just yet. (Not that it solves any other of crocket's stated problems, but it's init system agnostic.)

- John
And Void. Do not forget Void Linux. ;-)
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
hypoon
n00b
n00b


Joined: 28 May 2016
Posts: 15

PostPosted: Thu Mar 01, 2018 9:28 pm    Post subject: Reply with quote

I strongly disagree with "If it ain't broke, don't fix it." as applied to software updates. Serious bugs can often be invisible to the end user, especially if they're security bugs. Users shouldn't be expected to know when old package versions "ain't broke".

Furthermore, when something eventually does break, the process of updating to a new version is sometimes complicated if the package has not been updated recently. In my experience, a Gentoo box that hasn't received any updates for more than a year isn't worth trying to update anymore... it's better just to reinstall.

Haskell does manage package dependencies pretty strangely. The API is intended to be consistent if the first two numbers of a version string match. I have no idea how well developers adhere to this rule, though.

As far as I can tell, multiple package versions do not conflict with each other on a Gentoo system (I would appreciate it if someone else can confirm this). The ideal way for Haskell and Portage to interact may be just to slot every version of every package. Upgrading would involve installing the new version, rebuilding anything that can utilize the new version, and then letting depclean remove the old version if it's no longer required by any other packages.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7071

PostPosted: Thu Mar 01, 2018 11:36 pm    Post subject: Reply with quote

hypoon wrote:
I strongly disagree with "If it ain't broke, don't fix it." as applied to software updates. Serious bugs can often be invisible to the end user, especially if they're security bugs. Users shouldn't be expected to know when old package versions "ain't broke".

Furthermore, when something eventually does break, the process of updating to a new version is sometimes complicated if the package has not been updated recently. In my experience, a Gentoo box that hasn't received any updates for more than a year isn't worth trying to update anymore... it's better just to reinstall.

Not my own experience, i don't update that much, and i'm happy like that, the security is never invisible, and you will be advise when security issue is present (glsa-check is your friend).

It's only because of bad habit from some users to reinstall because they don't get what is going on, that they don't learn what is going on and have trouble handling just an update, something they should never be scared of, even if date between updates is huge.
I'm mostly sure that it's always a bad bet to reinstall ; sure installing may appears faster, but you endup with a basic gentoo ; if you go configure it the way it was prior reinstalling, i think you lose the bet as time is much much higher than time that should had been invest to fix it.
Only good bet about reinstall is for new user, they don't loose anything as they have just install a new gentoo, and reinstalling will teach them "but a few", but they will endup with the same gentoo as they didn't had time to actually do anything with it.
Back to top
View user's profile Send private message
sitquietly
n00b
n00b


Joined: 23 Oct 2010
Posts: 59
Location: On the Wolf River, Tennessee

PostPosted: Fri Mar 02, 2018 12:00 am    Post subject: Re: Are there alternatives to gentoo that solve these proble Reply with quote

crocket wrote:
I moved from ArchLinux to Gentoo because systemd and AUR were frustrating me with various issues.
I liked the fact that Gentoo treats third party, local, and official repositories seamlessly.
However, gentoo has a few issues... What alternative OSes do you recommend? I want

  • Rolling release
  • Independence from systemd (and pulseaudio). Ideally, I want to avoid dbus, too, but I couldn't avoid it on any OS I've used so far.
  • Ease of managing third party and local repositories
  • Stability of binary packages in official repository
  • Stability of third party repositories. I mean issues like https://bugs.gentoo.org/555266
  • Smooth upgrade without errors (I don't want to use haskell-updater and perl-updater because emerge fails with errors during upgrade.)


I have appreciated Gentoo and Funtoo (and Calculate) Linux having followed a path similar to yours.
There is no right or best amongst Arch, Gentoo, Funtoo, and Calculate Linux, but there are systems
that satisfy your particular needs, and systems that don't. Presently I have Calculate Linux installed
and I think that it may satisfy you -- they use the Gentoo portage tree and take advantage of portage's
ability to install binaries from a binary repo whenever there is a binary available that satisfies your
masks and USE settings.

Calculate Linux developers now have more than 10,000 of the Gentoo packages available as pre-compiled
binaries and they build that entire set as one unit so that build problems between those are resolved
before the ebuilds and packages are released to you. They have a really nice installer that will give you
a KDE Plasma (preferred) or Mate or XFCE or barebones system. Libreoffice will always be available as
a binary and always work. Your overlays are supported and emerging a package from an overlay will,
of course, build it from source. It would be best if using Calculate to not change their USE flags,
otherwise you would get a big re-build of your system from source (but it would possibly have fewer
blocks and failures because the entire set of versions have been built together on the Calculate Build
Server). They enable dbus and pulseaudio -- not ideal for you perhaps.

I also have, and generally use for my work, OpenBSD Current. It may tick all of your boxes of "wants".
It is rolling release and everything I need is available and always at the latest upstream release;
libreoffice, gnome, chromium, firefox, thunderbird, texlive, texmacs, texmaker, gimp, krita, etc.
(but NOT kde plasma -- only a few plasma apps are ready and the plasma desktop support is still some way off).
There is no need for pulseaudio because the OpenBSD sound server satisfies the need. There is no systemd,
the BSD init system is simple, flexible, and 100% stable and reliable. I love it.

To compare Gentoo and OpenBSD package availability check https://repology.org

The OpenBSD Current base operating system is updated every few days and the new snapshot can be
painlessly installed at boot time. The packages are rebuilt as a set every few days and updates are installed
by "pkg_add -u". The package manager is very reliable and full featured. I have no trouble with haskell
and perl updates, it seems to be handled nicely by the package manager.

OpenBSD does NOT support Nvidia graphics or bluetooth or usb audio or Google Chrome for Netflix.
Uncommon stuff like Ada programming tools are not available. Could be a show stopper for some folks.
The developers all run OpenBSD on their notebooks so it runs well on most hardware. There is no bad
politics, but also no support for newbies -- read the extensive user manual (the FAQ) and learn to read
the almost perfect man pages, or go away. There is a visionary, opinionated, BDFL with a great team
behind him.

Your personal repository can be supported by putting your "ports" in ports/mystuff directory and building
them from source -- that requires learning the OpenBSD ports system and writing a Makefile for your
package. I build all of my installed OpenBSD packages and my personal packages in a chroot using the
"dpb" command which is used to build the main OpenBSD binary repository. The ports are kept
so clean that I have never failed to rebuild all of my packages in one go by issuing one command.

Another joy is that the built ports do not pollute the running system -- when everything is rebuilt the
binary packages are available in a local repository and THEN the running system can be updated from
that repository (and of course other local machines can share that repository).

I fear that I am "selling" OpenBSD but don't mean to give you anything but some basic info with a
suggestion that it may be interesting to you to at least look into it.
Back to top
View user's profile Send private message
hypoon
n00b
n00b


Joined: 28 May 2016
Posts: 15

PostPosted: Fri Mar 02, 2018 12:31 am    Post subject: Reply with quote

I expect glsa-check to catch the major stuff, but not all bugs are identified as security bugs at time of patching. Sometimes it's discovered much later, when the patches have been available for a long time, but not everyone uses them yet. I recently listened to a video of Linus Torvalds discussing this exact point, where he refuses to ever mark kernel bugs with a "security" label. His argument is basically that most bugs can be security bugs if someone is clever enough.

I once had to locate old portage archives (they call it the "attic", I think?) in order to rescue a Gentoo system because the transitional packages were no longer in the tree. This was not recent, and I don't remember what caused the issue, but it was much more trouble than it was worth. If you keep your configuration organized, redeployment can be rather quick and painless. Redoing my systems every six months keeps me from getting too attached and forces me to adopt reasonable data integrity measures. These habits also reduce reduce downtime when "bad things" happen.

Over the past few years, I've started updating world every day. I spend much less time tracking down messes of blocking packages and interdependency hell. It may be that the issues are much easier to solve if encountered independently. Actually, every recent issue in memory has been an easily reverted commit to the Haskell overlay, which is a lot easier to diagnose when you don't have much to update. It's a bit annoying, but I'm optimistic that it'll be resolved eventually.

The best thing I ever did was to create a cron job to sync the tree overnight and email me a copy of a pretend emerge world. This makes me much more inclined to run the update when I get to work (or fix something first if needed), and even when I can't update for a few days, I can see in day-by-day resolution what changed and created the blockers (or whatever other issue might arise at the time).
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2574

PostPosted: Fri Mar 02, 2018 1:02 am    Post subject: Reply with quote

hypoon wrote:
I strongly disagree with "If it ain't broke, don't fix it." as applied to software updates. Serious bugs can often be invisible to the end user, especially if they're security bugs. Users shouldn't be expected to know when old package versions "ain't broke".
For your system, yes I agree. If you are talking about a niche program, or series of programs, like Haskell then updating weekly or even monthly is overkill.

I know that overlay well. It doesn't have the best quality and if the goal is just to run a single app then the constantly updating the dev products isn't doing anyone any good.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
hypoon
n00b
n00b


Joined: 28 May 2016
Posts: 15

PostPosted: Fri Mar 02, 2018 1:18 am    Post subject: Reply with quote

That's fair enough. The nature of Haskell drastically reduces the likelihood of certain types of bugs, and I'm of the impression that a large number of version bumps are for minor new features or performance improvements, although I have no data to support this notion. So for Haskell specifically, you're probably right.

I'm actually not 100% sold that the overlay is the right approach to maintaining a Haskell stack on a machine. At least one Haskell development workflow involves keeping a separate complete set of all the project dependencies stored with the project itself (I think this is Cabal sandboxing, but I don't use it personally, so I could be mistaken). This development workflow lends itself to having a lot of software needing a huge assortment of specific versions of dependencies. That's not how shared libraries typically behave, and Portage is not designed to handle that situation (though it may be capable anyway).
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13842

PostPosted: Fri Mar 02, 2018 2:40 am    Post subject: Reply with quote

crocket wrote:
Emerge fails during upgrade. When emerge fails, it tells me to use 'haskell-updater'. So, I use it. I use haskell-updater once per week or once per two weeks.
Minor point here. emerge is a command from Portage, which runs the ebuilds, which come from the tree and various overlays. Portage has no files which would give you this advice. However, some files in the Gentoo package tree do cause this advice.
crocket wrote:
I don't want to avoid using hledger just because of packaging issues. Despite issues, haskell overlay is the easiest way to manage hledger, stack, and other haskell packages on Gentoo.
Yes, overlays are much better than installing it outside Gentoo. Your best bet would be to fix the packager to stop using upper bound dependencies. Your second best bet would be to fix the packager to be more diligent about testing the dependencies before publishing new versions. The latter is much more work, which is why I keep advocating the former.
crocket wrote:
I think https://bugs.gentoo.org/555266 is the best gentoo developers can do because both gentoo and haskell can't change their package management system.
I disagree. Both parties absolutely can change their package management practices, given good reason to do so.
crocket wrote:
I don't care about how silly upper bounds are, but I want smooth upgrades as a user.
With automated warnings from repoman or some other software, haskell overlay maintainer can avoid breaking haskell packages every week.
Then we are in agreement that the packager should do a better job of managing the dependency information. We disagree on the details. You want him to conform to the practices of upstream Haskell, which require special (currently non-existent) tooling to avoid routine breakage. I want him to choose a path that is less work for everyone, including him.
Back to top
View user's profile Send private message
hypoon
n00b
n00b


Joined: 28 May 2016
Posts: 15

PostPosted: Fri Mar 02, 2018 3:04 am    Post subject: Reply with quote

The packager isn't choosing the upper-bound dependencies. They come from the software developers. While I don't necessarily agree with it, it's the way hackage (central repository for all things Haskell) does it, so it's the way most Haskell developers end up doing it. There exists an automated tool (hackport) for creating ebuilds from hackage, and I assume it's used to generate most of the ebuilds in the overlay.

By comparison, it sounds like a ton of work to go through every ebuild in the overlay and cross-reference the corresponding Haskell source code with multiple versions of its dependencies to determine a more reasonable upper-bound version, or make the judgement call that the library's API seems stable enough to remove the upper-bound version altogether.

In other words, my understanding is that the Haskell overlay functions similarly to a compatibility layer between Portage and Hackage. There are two things I really don't understand. First, why delete old versions from the tree? Is storage space for ebuilds that tight? Second, why do I have to mask a new version to prevent portage from trying to upgrade it despite the fact that portage knows the upgrade exceeds the upper bounds of other installed packages (and complains about it)? Shouldn't portage understand that the new version does not meet the dependencies of an installed package, and therefore should not be upgraded?
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2574

PostPosted: Fri Mar 02, 2018 3:52 am    Post subject: Reply with quote

Portage is designed to be a powerful tool for a power user, not an AI. Portage stabilization criteria in the main tree dictates that for a package to be stable all of its dependencies must be as well. If the developers do their job right you never have a problem with mixing stable and unstable unless you choose that path yourself.

An overlay need not adhere to this as they can do whatever they like. Unfortunately this confuses portage since there are a large number of ways to proceed. All it can do is present the information and beg for help.

I have no idea why the maintainer wouldn't want older ebuilds around. Maybe it is just to prevent too much cruft from building up and causing another headache. However, I will venture a guess that the dependency nightmare is a large reason Haskell is not fully supported in the portage tree.

As I've said before, I've played with Haskell and it is a nice language, but I think the overloads have made it such a mess that no one really wants to develop in it. Other functional languages (like lisp) do not have this problem and are widely used (despite somewhat user friendly not being).
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13842

PostPosted: Fri Mar 02, 2018 4:44 am    Post subject: Reply with quote

Yes, it is a significant amount of work to check the dependencies if you cannot assume new library versions are backwards-compatible. That is exactly what the Haskell package maintainer is required to do now, every time a new version comes out. Somehow, every other language supported in Gentoo manages to maintain enough backward compatibility during library upgrades that the general standard is to assume new versions won't break things. In those cases where that assumption fails (OpenSSL-1.1 comes to mind), the new version gets masked until the problem is resolved.
Back to top
View user's profile Send private message
crocket
Apprentice
Apprentice


Joined: 29 Apr 2017
Posts: 213

PostPosted: Fri Mar 02, 2018 5:12 am    Post subject: Reply with quote

Let me summarize.


  • Repoman doesn't check upper bounds, so haskell overlay maintainer makes mistakes often. https://bugs.gentoo.org/555266 tracks this issue
  • ebuild EAPI=6 cannot track fine-grained ABI changes of haskell packages, so haskell-updater is needed for now. https://bugs.gentoo.org/449094 tracks this issue. EAPI=7 will fix it.
  • libreoffice-bin breaks often due to reasons unknown to me. I have never had other binary packages like firefox-bin and google-chrome broken during upgrades. While it is true that binary packages will break eventually due to ABI changes, libreoffice-bin seems to break due to other factors.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2574

PostPosted: Fri Mar 02, 2018 5:22 am    Post subject: Reply with quote

I can explain (some) of the Libre stuff. Libreoffice is a big build that links to many, many other libraries. It also has a relatively slow release cycle.

Firefox and chrom(e/ium) update with regularity and most of their libs are bundled, ie shipped with the binary. This means less to break and the builds are refreshed more often thus preventing bit rot.

I understand why the bin options exist, but I dislike them because portage is fairly good at detecting when they break but the only solution it can offer is to reinstall it. That works for a source package but it doesn't fix the problem with the bin.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
crocket
Apprentice
Apprentice


Joined: 29 Apr 2017
Posts: 213

PostPosted: Fri Mar 02, 2018 6:28 am    Post subject: Re: Are there alternatives to gentoo that solve these proble Reply with quote

I think I'll stick to gentoo on my desktop. But, I'd like to try other OSes on my laptop.

sitquietly wrote:
I also have, and generally use for my work, OpenBSD Current. It may tick all of your boxes of "wants".


I think FreeBSD is similar to OpenBSD. Do FreeBSD and OpenBSD allow me to forgo pulseaudio without much hassle?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum