Core: https://packages.microsoft.com/rhel/ alias

[brianjmurrell]

Hi.

I am most sure that I am not asking this in the correct place but if not, I hope you can redirect me to where this could be asked.

Currently, I can download the dotnet packages for RHEL/CentOS (generically known as EL, or epel) from https://packages.microsoft.com/rhel/. It would be most helpful if an alias for that, to https://packages.microsoft.com/epel/ could be created. _epel_ is the generic non-vendor specific name for RHEL and it's variants.

[joperezr]

You are right that Standard is not the right spot to get that addressed 😄 , I'm not 100% sure this will be the right place either, but I would probably ask this in https://github.com/dotnet/core repo instead. @janvorli would you actually know what the right repo to ask this would be?

[janvorli]

I am sorry for missing the question before. I think that the dotnet/core would be appropriate for this kind of request.

[dagood]

From what I've seen, EPEL is a specific project and it would be misleading for Microsoft to host a unaffiliated repository with that name. EL could make sense though.

However, note that these pages don't point to packages.microsoft.com at all:
https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-manager-rhel8
https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-manager-rhel7

@leecow @nakarnam do we support using the rhel directories on packages.microsoft.com?
/cc @NikolaMilosavljevic

As for the request, I'm doubtful we'll be able to do it. This would be a feature request for the packages.microsoft.com team (mirroring a symlink?), and they're already swamped.

How does the repo name affect you?

[leecow]

Yes, we do publish to the rhel directories and while I agree that it would be nice to match the naming convention, these have been 'rhel' for several years now and changing would probably break an unknowable number of things.

[brianjmurrell]

From what I've seen, EPEL is a specific project

Not really. It is the name of a project, but it is more generally used to signify any Linux distribution that is compatible with RHEL. If you look at the mock project for example, in their configurations for different O/Ses you can see they use the name "epel" generically to define a configuration that works on any RHEL-derived O/S.

and it would be misleading for Microsoft to host a unaffiliated repository with that name.

It's not the name of a repository. It's the generic name for a distribution family.

EL could make sense though.

But it doesn't solve the problem at hand, and that's that in build systems like COPR which builds upon mock, one can refer to a variable called $distro in one's repository configurations and $distro resolves to _epel_ for EL builds.

However, note that these pages don't point to packages.microsoft.com at all:
https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-manager-rhel8
https://docs.microsoft.com/en-us/dotnet/core/install/linux-package-manager-rhel7

Those instructions only apply to RHEL and not RHEL-derived OSes like CentOS that don't have RHEL's subscription-manager.

As for the request, I'm doubtful we'll be able to do it. This would be a feature request for the packages.microsoft.com team (mirroring a symlink?), and they're already swamped.

I'm not sure I understand how adding a rhel/ -> epel/ symlink on https://packages.microsoft.com/ has any relevance to a swamping issue.

How does the repo name affect you?

As above. It means I cannot refer to https://packages.microsoft.com/$distro/$release/ when trying to configure a multi-distro package (i.e. something that builds on Fedora, EL7, EL8, etc.) on COPR.

Yes, we do publish to the rhel directories and while I agree that it would be nice to match the naming convention, these have been 'rhel' for several years now and changing would probably break an unknowable number of things.

I'm not looking for a change. I'm looking for a simple "pointer" in the form of a symlink. Much in the same way that https://packages.microsoft.com/rhel/7/ (likely, hopefully -- it's wasteful if it's not) is just an alias/symlink for/to https://packages.microsoft.com/rhel/7.4/

[dagood]

I'm not sure I understand how adding a rhel/ -> epel/ symlink on https://packages.microsoft.com/ has any relevance to a swamping issue.

I'm referring to them not being able to take on new features. They have a significant backlog of critical features for maintainability and reliability of the repos. About why I think they'll need to treat this as a new feature:

Much in the same way that https://packages.microsoft.com/rhel/7/ (likely, hopefully -- it's wasteful if it's not) is just an alias/symlink for/to https://packages.microsoft.com/rhel/7.4/

Unfortunately not. I don't think symlinks are in use anywhere in these repos.

---

That all said, I think it's reasonable for us to ask them (thanks for the extra context!) but I wouldn't expect them to be able to do it.