| View previous topic :: View next topic |
| Author |
Message |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20087
|
 Posted: Tue Oct 17, 2023 9:43 pm Post subject: |
 |
|
| szatox wrote: | | Partially because it was a simple fairness test. I intended to make the OP uncomfortable enough to realize why redirecting attention from other distributions to Universal Build Platform Gentoo would not be seen as beneficial by anyone outside Gentoo. Too bad, it didn't work. |
Would that not also be a fairness test for others? If all human packaging resources went to a common solution, that would seem to benefit everyone. As Gentoo is not a distro itself but a set of tools to build a distro, it makes perfect sense. The likely downside is in the migration. And it might not be worth the effort.
Using similar "fairness test," I have to ask what every distro's "ebuild" format does differently that isn't addressed elsewhere. I'm specifically excluding "it works with our distro" because that's a separate issue.
| szatox wrote: | | I don't think it's better to use Funtoo for building a distro that isn't Funtoo, just like I don't think it's better to use Gentoo to build a distro that is not Gentoo. |
Except Gentoo isn't a dstro in the same sense. It is a set of tools to build a distro. ChromeOS(?) is the usual example.
| szatox wrote: | | On top of that, an already independent distro has no business becoming dependent on anyone else. Giving up control to receive additional complexity is just a bad deal. |
Distros are already dependent on everything they include. Kernel, X, etc. In the Unified Future That Won't Happen, Gentoo as a "distro" could cease to exist beyond Portage and possibly some other tools used by everyone.
| szatox wrote: | | This said, Funtoo encourages collaboration more; attempts to have groups of people with common use cases maintain respective profiles instead of individual admins maintaining individual machines on ad-hoc basis. "Do not set custom use flags, report a profile bug instead". |
Yeah, that's both interesting and adds complexity that I"m not sure is the appropriate solution. It seems like an attempt to move more toward a binary distro where there is no choice. I don't see how profile Foo that supports something I don't want should have a bug to disable it as others (presumably) want it. Profile Foo2 doesn't seem like a good idea, nor an improvement in managing the problem of using custom USE flags.
| szatox wrote: | | Blurring the lines between users and developers provides more manpower to the common cause; it would be much easier to run Funtoo Debian than szatox Debian, pjp Debian and minkanjin Debian. |
I agree that combining manpower to the common cause is the point. As far as I know, Funtoo still uses the core tools underneath to achieve the same goals, so Funtoo isn't fundamentally adding anything over Gentoo to facilitate the "common effort." As for Funtoo's "don't customize USE flags" approach, I would presume that could be retained in the tooling. The problem reduces to bootstrapping the tool set, and it wouldn't matter which distro was used.
| szatox wrote: | | Not that any of those would ever happen anyway. Maybe - just maybe - BloatPack Debian could be feasible. But flatpack and snapstore already exist, what's the point of making Lindows crowd bigger after package managers have already been invented? |
I'm not familiar enough with Lindows to know. I thought Microsoft bought it a long time ago and it no longer existed.
Besides, if package management was a solved problem, there wouldn't be so many choices. They're kind of like standards in that regard... so many to choose from :)
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
 |
minkanjin
n00b
Joined: 29 Jan 2017
Posts: 42
|
| Posted: Wed Oct 18, 2023 9:46 pm Post subject: |
|
|
I was going to post on the Arch forums at a later date. I figured people in this community should have a say first, since outsiders might not have the best idea of where to begin the conversation.
I figured the first distro I would go for is Arch, since it is a rolling release, and I believe some of their devs came from Gentoo.
Going for a non-rolling release would mean digging a lot of old ebuilds out of the trash, and then maintaining those ebuilds. That would require a lot of manpower just for maintenance, when we already need a bunch of people to add other-distro-features to Gentoo.
Most other rolling releases are based on Arch, so doing them after Arch should be easy.
Overall I think that Arch is the easiest option with the most reward.
But I don't actually know that, so I'm willing to hear if anyone would rather go for a different option.
Puppy seems like it might have useful tools we can adapt, but those seem to limit our options Ubuntu and Slackware, which I think will be difficult for previous stated reasons.
So we have to decide which is easier: porting distant distros, or adapting Puppy's tools for Arch.
Should I also invite the Puppy devs to this thread? |
|
| Back to top |
|
|
minkanjin
n00b
Joined: 29 Jan 2017
Posts: 42
|
| Posted: Wed Oct 18, 2023 9:55 pm Post subject: |
|
|
It would make things easier if we can gradually transition another distro to Gentoo. Particularly, building some packages with portage and some manually.
For that matter, I suspect a lot of ebuilds are already fairly distro independent. So maybe we should just take base Arch and see which packages, build by Gentoo, would run on it.
Can apps build on Gentoo dependencies run on manually build dependencies?
Could it be that simple? |
|
| Back to top |
|
|
pingtoo
l33t
Joined: 10 Sep 2021
Posts: 991
Location: Richmond Hill, Canada
|
| Posted: Wed Oct 18, 2023 10:23 pm Post subject: |
|
|
minkanjin,
If you thinking using Gentoo as basis to develop a strategy to incorporate other distro you will facing double whammy, precisely because Gentoo being rolling release and as well some other already advised in this thread, you will be chasing a change, it will be hard to support.
Inviting Puppy Dev into here for conversation will be premature at this point, because unless you are suggest emerge changes for the purpose to support a way to adoption for other distros. there is not reason to learn from Puppy of how to design for the adoption. As far as I know Puppy development history have never ask other distro join effort for them.
It would be much easier to pick a snapshot than develop a demo that someone can easier to understand and to follow.
Ebuild is just a recipe of how one application could be configured. it would not be difficult to change to support another distro's specific configuration, I am currently working on getting chromuim build for RPI4 for example. If I want to have ARCH flavor of chromium I would try to find out which chromium snapshot ARCH was based on and modify ebuild to match that version first, then check ARCH build system for chromium dependency in ARCH's version and work from there. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20087
|
| Posted: Thu Oct 19, 2023 1:03 am Post subject: |
|
|
I haven't read that much about how Puppy works, but it seems like they use upstream binaries. So Puppy Ubuntu uses binaries built by Ubuntu, and Puppy Slackware uses binaries provided by Slackware. I may be completely wrong. Portage tools may not do what they need to do to produce a finished product.
I wouldn't recommend approaching other communities to come here to discuss how they can change what they do and adopt Gentoo to do it. That's not how you're going to affect change.
It might be beneficial to learn what problems a distro wanted to solve that led to its creation, and subsequently how they solved those problems. Create a place to document that information. How does each solve the common problems? Presumably every distro has a build environment that automatically fetches source and builds it. Do some distros have common data that others do not? Distro applied patches might be an area with less common ground, but a lot of other details would be shared.
Then there's the issue of binaries, their packaging, and the approach used to implement them. Separate issues are going to involve politics and license purity (or lack thereof). The kernel may or may not be an easy starting point. It's common for all distros. That doesn't cover things like flatpak or guix, so there is a lot more ground to cover.
Then figure out what pieces are shared and document it. Then identify and document differences, followed by motivations / justifications for choices that were made.
At that point, people may become aware of your efforts and voluntarily contribute. If nothing else, it might be interesting from a historical perspective.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
ferringb
Retired Dev
Joined: 03 Apr 2003
Posts: 357
|
| Posted: Wed Oct 25, 2023 9:39 pm Post subject: |
|
|
| minkanjin wrote: | | It would make things easier if we can gradually transition another distro to Gentoo. |
So... take a step back here. You're assuming other distro's *want* the ebuild format, or that the ebuild format is representative enough to encompass what other distro's need.
Debian folks seem to like their format, as do RPM folks, etc. fbsd folks would probably respond to this request with "we were here first, perhaps you should rebase gentoo onto ports?". You get the idea; most packaging formats age are measured in decades, even if they've had extensions/revisions along the way. They see value in their format.
As to the 'representative' point; the ebuild format is heavily source orientated, including the metadata it supports. Take a look through RPM's specification for what metadata fields it supports; there are many, *many* things that are allowed there that doesn't exist in EAPI. The RPM folks added it for a reason; their primary problem domain (built packages- binary/ABI/and equivalent) is not gentoo's. I suspect you're new to gentoo, but trace the history for how long it took to add ABI into the atom spec (slotted deps); that idea was around from early 00's but landed somewhere after 2010 iirc. In gentoo that was a known breakage and pain point- tools were written to work around it, and generally your system got mildly broke a couple times a year if you weren't careful (python, perl, etc). This sort of thing doesn't fly in a binary distro- a broken build is a different beast from "I can't launch any c++ binary anymore".
To wit: no packaging format is truly a subset of another; for example, very few packaging formats actually have the concept of a 'slot'- having multiple package 'names' installed in parallel but being used both in version ranges and slotted version ranges. This is why in rpm/dpkg world you see python2- and python3- package naes; they don't have the slot concept, thus they're stuck pushing the major version into the packagename. That in turn makes their dependency chain have to know shit like "I rely on python2-sphinx, not python3-sphinx". Effectively parallel dependency chains... which is fucking annoying to deal with in my biased view, but they seem fine w/ it.
| minikanjin wrote: | | Particularly, building some packages with portage and some manually. |
Trace into tools like https://sourceforge.net/projects/alien-pkg-convert/alien; there are ways to take a directory and wrap it into a given binary format and inject some metadata into it. None of them do inferance for deps (that I know of), so this is heavily manual and requires the person translating it to know the package 'universe' they're targetting. By universe I mean "is it called python3-jinja2 in that distro, or python3-jinja? Or have they phased python2 out and just call it python-jinja?". Etc.
| minikanjin wrote: | | So maybe we should just take base Arch and see which packages, build by Gentoo, would run on it. Can apps build on Gentoo dependencies run on manually build dependencies? |
You need to look into things like ELF linkage and ABI. I can grab a pkg- the binary- and slap it into random OS's; whether or not it works is irrelevant to the packaging/containing format; that 'format' is to carry the metadata necessary to model/define the actual sort of dependencies I've been talking about.
Please note that I keep talking about ELF/ABI, but there are many forms of dependencies beyond that; ELF is at least a static definition. Most aren't. Enumerating a couple:
- python modules; the actual module loaded is dependant on the invoking python interpretator, and the 'import' doesn't have to be constant string. Anything that supports a basic plugin framework winds up doing something like
| Code: | | plugin = __import__(some_dynamic_string_variable) |
which coupled w/ python's ability to do truly heinous metaprogramming shit, makes this require a human stepping in and manually specifying a fair amount of dependencies.[/code]
perl, php, ruby, etc. All have the same issue. Basically any interpreted language hits this.
...and compiled languages hit it also. C/C++ has dlopen, java's obviously got some plugin trickery, etc.
Shell scripts can invoke whatever the hell they want which in turn means one must extract the binaries they call and convert that into packaging deps; again, humans frequently have to step in.
One other issue here is that the pathing between distro's is not always the same; things are standardizing (FHS, /usr split merge, etc), but the paths used on one distro may not be the same on others. Worse, those paths can be hardcoded into the resultant binary or script.
Trace into how nixos works; they've created some pretty fucking heinous ldloader tricks that allow them to have far greater control over this and to partially address/solve the problem. However, that would require building all binary packages the nix way- relying on the linker and versioned path tricks they use.
| minikanjin wrote: | | Could it be that simple? |
It ain't, and pardon if the above sounds like someone dumping a ton of bricks on you; I'm just trying to layout a sketch of the problem. 
Look into package frameworks if you want to pursue this further; basically something that can represent both RPM/DPKG/arch w/in the same library, support a common dependency resolver, common tooling, etc. To do what you're talking about, there has to be a lowest common denominator expression of the format features, and then tooling built to work with that; having that makes it more viable to do the sort of mapping between a binpkg in one distro/release, to another. Consider that a 'step 1' along the path to your end goal.
As to frameworks, there are folks who've built common libraries for the dependency solver issue; gentoo doesn't use any of these purely because the possible package/use flag combination is exponentially worse than what binary packages deal in; ebuild resolver's have to be built to explore the solution space vs binary distro resolvers where they can hold the solution space (the underlying depgraph) fully and walk it in a reasonable time frame.
Hell, there is at least one distro that was built to allow deb/rpm interaction (since they're closer to each other than ebuilds are to them), but I'm skeptical for the reasons I laid out above.
Pkgcore was written to try and do the framework thing I mentioned, but it's fairly gentoo specific now. The underlying concepts aren't- and at one point there was experimental ability to play w/ .deb's- but that was sketch at best. I know there are other frameworks that exist these days, but can't give names since I've been away from this particular problem for a long while.
Either way, hope the above is informative.
[/random drive by posting from a retired dev] |
|
| Back to top |
|
|
minkanjin
n00b
Joined: 29 Jan 2017
Posts: 42
|
| Posted: Fri Dec 22, 2023 4:06 am Post subject: |
|
|
Not really that new to gentoo. I am aware of some of the struggles we had. For that matter I suspect every distro have such struggles. Better to have the struggles in one place where everyone can get it fixed quickly.
However, I am new to a project like this, which is why I'm hoping others would know better.
If the fbsd was there first, then we should look at that. Of course, it is not really about who had it first, but which system would be easiest to adapt for everyone.
I expect we would have to make some modifications to how gentoo does things, to accommodate things like extra metadata.
I think the other distros can benefit from our "slots", and probably a few other things. And we might benefit from some of their things.
But for now we don't need to worry about all the other ways of doing things, we just need to worry about getting Arch to work.
| ferringb wrote: | | is it called python3-jinja2 in that distro, or python3-jinja? Or have they phased python2 out and just call it python-jinja? |
That makes it a bit more complicated. There will be some politics over whether we should adapt to their way, or they to our way.
I'm hoping Arch is close enough to our way for there to not be too many problems like this.
Maybe if everyone switches to the same way of doing things, making python work will be easier for everyone.
If nixos' ld tricks are so powerful, maybe that should be something we should be looking at. Unless it is powerful at the cost of sanity.
Maybe we should just focus on one framework for now. Like I said, I think we need to focus on just Arch for now. |
|
| Back to top |
|
|
minkanjin
n00b
Joined: 29 Jan 2017
Posts: 42
|
| Posted: Fri Dec 22, 2023 4:10 am Post subject: |
|
|
I rediscovered OpenEmbedded a few days ago. It has a build system similar to gentoo, but it is focussed on crosscompiling binary packages. Including debs and rpms.
On the surface this seems to be very relevant here.
Is anyone familiar with their system, or have any opinions on OpenEmbedded?
Not sure if a lot of people use OpenEmbedded any more. |
|
| Back to top |
|
|
|
|
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
|
|
Gentoo Chat
