Discussion about packages in the EndeavourOS Repository vs. AUR e.t.c

Regardless if the OP has added the EOS repos correctly or not, I have a different issue.

Reflector-auto should be able to run on any arch based system, or not? There isn’t anything EOS specific as far as I can see.
Why is this part of the EOS repos then and not added to AUR where a lot more people could benefit from it?

I haven’t added and won’t add the EOS repos to all my machines, but would still like to benefit from software like refelector-auto, btw.

With the build instructions everyone running arch in some form can install reflector-auto, not just EndeavourOS users!
But I would rather see stuff like this added as standard package or AUR, so a simple yay… would always do the job, regardless if you’re running EOS or not.

I mean this was formerly called reflector-antergos afaik and I wouldn’t be surprised if it also lives on as manjaro-whatever; until the projects and repos die.
Please keep the EOS only repos as small as possible and don’t go the Manjaro way. It’s only a small step to renaming it endeavouros-refelector-auto … :wink:
Wouldn’t like that at all.

2 Likes

good point… but contributing to the AUR is extra work needs time and afford to maintain it there.
it is simply born out of the need to have something like this for Antergos mirrors, and will be used like this in the future if the numbers of EOS mirrors getting big.
And there is already something same at AUR:
https://aur.archlinux.org/packages/reflector-timer/

2 Likes

I understand, but …

Then why not use and make a Wiki tutorial about that?

There is no need to get new users hooked up to a repo if there isn’t a very specific need.

I just don’t want to see the same mistakes being made over and over again (e .g future xyzOS saying …born out of the need for something like this for EndeavourOS mirrors).

“Once you start down the dark path, forever will it dominate your destiny, consume you it will…”
― George Lucas

The mistake would be to add one package after the other and let the repo grow to an unmaintainable monster.

There will be a need for it in the future so we choose this one at the repo.

If you want to discuss this more specific please open a new threat, as this is going far off-topic.

2 Likes

@2000
It certainly isn’t our intention to keep packages exclusively in our repo. At this moment we have our hands full by bringing EOS to the next level. The code is publicly available at Github, so we don’t keep it from public use. Even though I do understand your point, putting a package in the AUR is a lot of work, right at this moment. This doesn’t mean we’re not going to make it available in the AUR in the future.

I do like your enthusiasm and your passion for the distro, but keep in mind that at this moment it’s only four guys who are trying to keep the distro running. Once we’ve reached the next level and when there are more people who want to join the dev team, we have the time and resources to do it the way you described.

3 Likes

@2000 @Bryanpwo
Moved to its own topic, as i am strict on not going off-topic on help-channels, special if the issue is not solved and thread is waiting for a response from threadstarter.

@2000
A great solution to your issue is you put relfector-auto to AUR.

Here’s all that you need from the EOS side: https://github.com/endeavouros-team/PKGBUILDS/tree/master/reflector-auto

1 Like

@Bryanpwo @joekamprad
OK, sorry for being such a pain in the a… Good move turning this into its own topic; didn’t mean to hijack the old thread. But my vacation is over anyway so I won’t be posting at this rate from now on, now that I’m back in the real world. :wink: So please bear with me.

I can’t imagine the stress and workload you guys are managing at this early stage in the project. I’m amazed and appreciate that you even take the time to comment on this forum as much as you do. The time frame in which you got all this done is exceptional, so I’m not proposing you do more work even faster. However …

In my experience it’s exactly in these early project stages where corners are cut, shortcuts are taken and bad habits tend to arise. Now, I’m explicitly not stating that this is the case with you guys but I do believe every project profits from Advocati Diaboli questioning motives, plans and overall approach.

I genuinely thought the idea of EndeavourOS was to provide an easy install with a choice of nicely themed DE’s (later on). Set up some important stuff to get the system running and otherwise stay as close to pure arch as possible.
Now, I think having software in an EOS repo only is diametrically opposed to this.

Stuff like a special grub-theme, keyring, mirrorlist etc. belong in an EOS repo.
Applications like kalu, downgrade, yay etc. have an AUR entry also and will be accessible through AUR even if the EOS repos would happen to go down.
But nvidia-installer and reflector-auto for example are EOS repo only.

Nice to hear that you are planing on rectifying this in the future. I’m really not pressuring you to do this right away, btw. I understand the need for testing or merely not having fully decided if or how to use certain applications etc. So there will always be some EOS only software that hasn’t found its way into the AUR, yet.

I question the prohibitive “lot of work” aspect though: You already have your own repo, you have a github account where the sources reside, you have PKGBUILD’s, you’re distributing so you’ve got the licensing checked.
All you need now is an AUR account and to provide these PKGBUILD files. So you’ve actually already gone about at least 90 percent of the way.


Until then, I propose that in the future you explicitly add the information that certain software is EOS-repo specific to Wiki tutorials like “Automatic Rank the Mirrorlist”. Having some tutorials that work for other arch based distributions and some tutorials that don’t is confusing.

At least for me. I genuinely didn’t reckon with this; that’s why I assumed the Wiki tutorial lacked some information when a user posted his problem installing through pacman in Reflector-auto is not found by pacman.

1 Like

@manuel
So you’re proposing I or somebody else not affiliated with EOS add stuff I deam worthy to the AUR; and to ignore software I don’t?

Or are you proposing I do this for all the packages EOS adds to its repo in the future?

C’mon! This isn’t just about reflector-auto; you’ve missed the point and are simply being petty.

Of course I could adopt and maintain this, but aside from licensing issues, like not knowing where the original source came from or if it’s genuine EOS software there’s a more fundamental aspect to “my issue”.
Is EOS going to fill its repo with EOS-only stuff, initially pulling a Manjaro, or not? Now, this is a binary issue; it’s either yes or no.

As I understand Bryan and Joe from their previous posts it is not going to be EOS-specific and it is just a matter of time before things are added as official package or as AUR.
I’m good with that.
For me personally, this is the single most important feature I’m looking for in my potential new distribution. A beautiful themed DE is nice to have but I’m more interested in staying as pure arch as possible. Otherwise there are multiple other arch based distributions, most also with their own repos, nicely themed, that install just as easy.


To the matter of adding AUR packages I will quote myself:

(“You” being EOS)

1 Like

We are certainly not going to pull a Manjaro and I already stated on how we’re working and going to work, as for the original problem. The OP has a problem with the settings of the installed system, because if you’ve read the other comments also, they stated that they could install reflector-auto with yay.

I appreciate your questioning, because that’s a good way to improve, but we are traveling a certain path and luckily there are coders who are showing interest to help us.
That is the biggest problem, lack of man force, therefore we’re not cutting corners, we’re prioritizing.

Forgive Manuel or Joe or Fernando, since they work much closer to the distro source then I do, so they are a bit more passionate when defending their work.

Again give us time and I promise you, if we’re still at this level ten months from now, you have every right to be upset about it. For now, take a deep breath and let us get this distro really rolling.

2 Likes

@Bryanpwo that’s good to see, because what made me stick to EOS and almost instantly love it, is that it is so SO close to mint arch, that I wouldn’t even expect, especially with such polished DE.
I totally agree with @2000 that it would be significantly better to keep it that way.

On the other hand, arguing about putting that package into AUR makes no sense to me… I mean, I also got the @manuel point. And that’s why I decided to help you guys with aur - I think that I can handle submitting AUR packages. I’m not experienced at all, never did that before but I really care about EOS, want to help somehow, so I’ll just learn how to submit AUR packages, and hopefully take one small responsibility off the team shoulders. Also I believe I will learn something that will make me a better sysadmin :slight_smile:

2 Likes

A user in another topic had difficulties following a Wiki-tutorial because his EOS-repos were borked. That’s why Pacman/yay couldn’t find the package. As this package isn’t anything that wouldn’t function on any other arch distro I merely questioned it not being in AUR also.
That specific package was just a placeholder for suggesting everything not EOS-specific be added to official repos or AUR (at a later stage of the project!). Why keep stuff from the wider (Arch)-Linux community?

While I really acknowledge your commitment :+1: , this is exactly what I would prefer not to happen because it could cause problems in the future.

In this case it would explicitly not be EndeavourOS keeping their repos lean, it would be a user not affiliated to EOS in any way doing it. What happens if you decide to stop maintaining them or decide for whatever reason not to add new stuff?
I think it would be better in the long run if packages where maintained by EOS itself.

Anyway, as I conclude from their answers above it is just a matter of time before things are added as official package or as AUR by EOS-devs themselves, therefore becoming a unique selling point compared to other distros. Or did I misunderstand?

1 Like

No, you didn’t.

1 Like

Thanks!

Now that’s confusing. What happens if any dev decide to stop coding for EOS? Or anyone else doing anything for the project? The same applies for everyone, I don’t really accept this argument. When I decide to get into it, then I will do this as long as I can/wish to, when I decide to quit, then it will be something to discuss.

Since that OS is community driven, and team is telling us that they’re short on human resources, then why not accept some help?

Then the distribution is officially dead!

“as I can/wish to”: You, yes, not EOS. Exactly my point!

No, unfortunately you seem to have misunderstood my objections. I’m not trying to keep you from helping by maintaining AUR packages.
I just question the idea of doing this a a private non EOS affiliated user opposed to doing it as an official EOS-team member.
If you have the time you could maybe become the official “EOS AUR maintainer” :wink: .
If you then ever decide to quit, maintaining the AUR packages would still be EOS’s responsibility. In the long run it is always better to separate between task and person.

Okay, that is a good point, now I get it :wink:

https://aur.archlinux.org/


:100:

1 Like

May I ask, what is the difference between EOS’s reflector-auto and the reflector version that is already in the Arch community (non-AUR) repo? As a non-coder, I’ve gotten lost regarding the underlying reason for reflector-auto being separately maintained. Thanks for dumbing this down for me.

@bkaplan
Really not much from the point of view of an ordinary user.
Program reflector-auto is by default a bit more configurable than reflector-timer, but both of them do the same job.

@judd
That disclaimer doesn’t mean what you’re hinting at. At least the way I understand your post, that is.

“User” in this context could be the EOS-team, -project, whatever. It just means that AUR packages aren’t officially endorsed and therefore could potentially be harmful.

From Arch User Repository

What is the AUR?
The AUR (Arch User Repository) is a place where the Arch Linux community can upload PKGBUILDs of applications, libraries, etc., and share them with the entire community. Fellow users can then vote for their favorites to be moved into the community repository to be shared with Arch Linux users in binary form.
What kind of packages are permitted on the AUR?
The packages on the AUR are merely “build scripts”, i.e. recipes to build binaries for pacman. For most cases, everything is permitted, subject to usefulness and scope guidelines, as long as you are in compliance with the licensing terms of the content. For other cases, where it is mentioned that “you may not link” to downloads, i.e. contents that are not redistributable, you may only use the file name itself as the source. This means and requires that users already have the restricted source in the build directory prior to building the package.
What is a Trusted User / TU?
A Trusted User, in short TU, is a person who is chosen to oversee AUR and the community repository. They are the ones who maintain popular PKGBUILDs in community , and overall keep the AUR running.
What is the difference between the Arch User Repository and the community repository?
The Arch User Repository is where all PKGBUILDs that users submit are stored, and must be built manually with makepkg. When PKGBUILD s receive enough community interest and the support of a TU, they are moved into the community repository (maintained by the TUs), where the binary packages can be installed with pacman.