[gentoo-dev] last rites: sys-devel/prelink, app-crypt/hmaccalc
# Andreas K. Hüttel (2022-01-22) # Prelink support is being removed from glibc and was # already somewhat broken for a while... # hmaccalc hard-depends on it (?). # Removal in 30 days. sys-devel/prelink app-crypt/hmaccalc -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On 1/20/2022 16:32, Rich Freeman wrote: > On Thu, Jan 20, 2022 at 4:10 PM Piotr Karbowski wrote: >> >> Ideally we'd have some way to mark binary packages with new EAPI and >> have FEATURES flag like 'prefer-binary' and go with -bin in case there's >> || ( ) dependencies list, regardless of the original order in virtual. >> This way everyone could be happy and not choose one workflow over another. > > Ideally we'd just have a repository of binary builds for everything > with default USE flags for a few profiles, and users could choose to > configure portage to just download the binary package if the flags > match, and of course this could be overridden per-package. Then there > would be no need for -bin anything. We have to maintain half of that > for the stage builds anyway. > [snip] I've learned from running FreeBSD on some of my network equipment that this is the path they take. They have flags called USES on their Ports system, and for binary packages, defaults are selected and used for building binary packages. In a handful of cases, such as mtr, they'll offer both an X11-enabled version as well as a non-X11 version of the binpkg. For all other cases, it's fairly straight forward to build a few packages yourself via Ports with your own USES selections. E.g., I don't need python support in bind-tools, so I build that one on my appliances myself to reduce the required dependencies that need to be installed. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On Mon, Jan 17, 2022 at 3:24 PM Georgy Yakovlev wrote:
>
> Hi,
>
> I've been approached multiple times with that request, and a lot of
> time I see new users completely destroyed by rust build time and disk
> space requirements.
What does this actually mean? Can we more clearly document the negatives?
Is it that Rust takes a long time to build? This seems like just a
consequence of a sourced based distribution. Many things take a long
time to build. I suspect rust is not the only package and again we are
back to staffing binhost like projects for much of the tree so that
this particular complaint can be mitigated, not just for rust, but for
any package.
Is it that Rust build fails because users lack the resources to build
it? We should be using check-reqs here to detect this pre-build and
give the user choices (like telling them rust can't be compiled from
source on their machine and to use rust-bin.)
I tend to empathize more with Peter Böhm later in the thread, in that
Gentoo is sourced based and I'd expect portage to be installing things
from source by default. Building from source is resource intensive and
expensive, yes. I think if you want a binary-based distro you are
using the wrong distro at the moment.
-A
>
> WDYT about switching order of rusts in a virtual?
>
> RDEPEND="|| (
> ~dev-lang/rust-${PV}
> ~dev-lang/rust-bin-${PV}
> )"
>
>
> becomes
>
> RDEPEND="|| (
> ~dev-lang/rust-bin-${PV}
> ~dev-lang/rust-${PV}
> )"
>
>
> Existing installs should be unaffected ofc.
> But portage may prefer to depclean rust and not rust-bin if both are
> present.
> Users who wish to use source version at all times can just add it to
> world file.
>
> I see both positives and negatives of doing that, but would like to
> reach out to community first.
>
> Thanks!
>
> --
> Georgy
>
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
On 21-01-2022 11:29:54 +0100, Peter Böhm wrote: > Dear Developers, > > I like your goal to make Gentoo more user-friendly but Gentoo is a source > based distribution and I dont like binary versions as a default. My question > is: > > Who has problems with "big" packages like rust or firefox ? > > Only User which doesnt know there is a binary version. So, in every case we > need to describe it in our AMD64 handbook. > > Am Freitag, 21. Januar 2022, 10:22:14 CET schrieb Mart Raudsepp: > > Anyhow, my vote is to default to rust-bin - people can easily be told > > to move to dev-lang/rust at their convenience and then explicitly > > depclean rust-bin. > > I am dreaming about another solution where this is not needed: > > In our /etc/portage/make.conf we can have a new: > > MAKEBIN="rust firefox" > > ... resulting in an automatic switch to the binary version of all included > packages ... of course this is also as recommendation in our AMD64 handbook > (with a clue to delete it if not desired). or ... if we could have Portage check the requirements for building a package, and if it cannot be met, that it tries to resolve the || case, which would be the -bin variant in this case. Not sure if the information is available to Portage at dependency resolution time though. Fabian > > Kind reagards, > Peter > > > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
Dear Developers, I like your goal to make Gentoo more user-friendly but Gentoo is a source based distribution and I dont like binary versions as a default. My question is: Who has problems with "big" packages like rust or firefox ? Only User which doesnt know there is a binary version. So, in every case we need to describe it in our AMD64 handbook. Am Freitag, 21. Januar 2022, 10:22:14 CET schrieb Mart Raudsepp: > Anyhow, my vote is to default to rust-bin - people can easily be told > to move to dev-lang/rust at their convenience and then explicitly > depclean rust-bin. I am dreaming about another solution where this is not needed: In our /etc/portage/make.conf we can have a new: MAKEBIN="rust firefox" ... resulting in an automatic switch to the binary version of all included packages ... of course this is also as recommendation in our AMD64 handbook (with a clue to delete it if not desired). Kind reagards, Peter
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
Ühel kenal päeval, N, 20.01.2022 kell 16:32, kirjutas Brian Evans: > On 1/17/2022 6:24 PM, Georgy Yakovlev wrote: > > Hi, > > > > I've been approached multiple times with that request, and a lot of > > time I see new users completely destroyed by rust build time and > > disk > > space requirements. > > > > I bet that the pending polkit merge request[1] (which is just about > ready and blessed but not merged by devs) would seriously drop many > people's concerns over rust. > > Using duktape on most systems will suffice for polkit once included. > > GNOME and Mozilla products still pull in spidermonkey but other users > will have a much reduced requirement for rust. librsvg, dev-python/cryptography (masked so far but eventually needs to move forard, albeit it looks like it won't have as big an impact as it once would have), probably rather more to come. Ühel kenal päeval, N, 20.01.2022 kell 20:01, kirjutas Michael Orlitzky: > Avoiding librsvg used to be difficult because it's required by our > GTK > icon packages to render PNGs from SVGs. Luckily dilfridge's binrepo > now makes it easy to download pre-rendered icons, and there's no > security/performance/legal concerns with pre-rendered PNGs, so using > them shouldn't present any moral dilemmata. You mainly just have to > replace Firefox, Thunderbird, and GIMP. And it is required on GTK itself to actually be able to render any SVG icons. I can not suggest avoiding librsvg with GTK, nor let such suggestions of such be uncountered. rust is a toolchain, just like GCC, and if you are running a source- based distribution, you get to have the toolchains required to compile from source. Anyhow, my vote is to default to rust-bin - people can easily be told to move to dev-lang/rust at their convenience and then explicitly depclean rust-bin. They can even use system-bootstrap on dev-lang/rust with rust-bin to do so, in some situations (~arch-only apparently). Mart signature.asc Description: This is a digitally signed message part
