Re: RFC: make $releasever return "rawhide" on Rawhide

[Kevin Fenzi]

On 08/03/2018 02:11 AM, Kamil Paral wrote:
> On Thu, Aug 2, 2018 at 12:23 PM, Miroslav Suchý  wrote:
> 
>> Dne 31.7.2018 v 15:04 Kamil Paral napsal(a):
>>> In short, package managers on Rawhide would no longer replace
>> $releasever variable with a numerical value (like '29' at
>>> this moment, soon '30'), but with 'rawhide' string instead. I hope this
>> change will make life a bit easier for
>>> third-party repos maintainers, for users, for developers and sysadmins,
>> and for release engineering. The technical
>>> implementation can be seen in the ticket (it's the 'Proposed solution
>> 1'), together with a long discussion.
>>
>> Just note that fedora-rawhide.repo has:
>> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
>>
>> Which now points to /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64 (on
>> x86_64 machine).
>>
>> So either this file need to be renamed to RPM-GPG-KEY-fedora-rawhide-x86_64
>> and updated on every branching or symlink
>> need to be provided.
>>
> 
> Interesting, this is something Kevin mentioned during the releng meeting,
> which I didn't completely get:
> 
> 17:09:15  also would fix a long standing issue around moving to
> rawhide from a stable relase and gpg key...17:09:35  because
> the gpg key file is called 'whatever-rawhide'  not 'whatever-29'
> 
> 
> It seems he was mistaken then?
> 
> But yes, the files would have to be renamed, thanks for a reminder.

Yeah, we finally did change it... for a long time it was rawhide which
confused people who passed the number.

Likely here we want a link from "rawhide" to the current number and
change that at each branching.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YGPPUJKOSS2R4EI4COMX3Z2YVGBHWVFK/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Kamil Paral]

On Fri, Aug 3, 2018 at 3:19 AM, Neal Gompa  wrote:

> And
> you're not quite correct about this. The way that DNF gets this value
> is through identifying the package that provides "system-release" or
> "distribution-release" and identifies the version set for the package.
> That version is what propagates to set $releasever.


Not quite. I have tested the patch in "Proposed solution 1" in the releng
ticket and it works. The code is here:
https://github.com/rpm-software-management/dnf/blob/
6517f47c94bdf2da2b1ce11605babee4d8cb8756/dnf/rpm/__init__.py#L29

If you set
system-release(releasever) = value
then 'value' is used instead of identifying the package version.

If you see a logical mistake somewhere, please tell me. But in my testing
dnf correctly used 'value' (i.e. 'rawhide') with this patch.


> Hilariously,
> PackageKit independently reads VERSION_ID from os-release(5) to
> determine this. These don't always agree. And in addition, it's
> impossible to stay on Rawhide through PackageKit without the controls
> through fedora-repos-rawhide forcing it.
>

Yes, that's mentioned in the ticket and in the introductory email here.
I'll need to ask PackageKit developers to use the DNF logic instead of
using a custom one. This is actually already "broken" - having two package
managers, each detecting releasever in a different manner - it just has
never been a problem in Fedora, because they've both arrived at the same
answer so far.


>
> And how do you propose people sync down from Rawhide to "branched"?


Again, it's in the ticket. Why wouldn't this work? (Once Branched == F29
and Rawhide == F30)

sudo dnf distrosync fedora-release\* --releasever=29




> Or
> sync up from an old Rawhide to "branched"/"stable" which this change?
>
>From what I can tell, that wouldn't be easy.
>

It should work with the same command as above, shouldn't it?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NXG6XYXIZGWGUHMZZVW5F2OW55CXAAFA/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Kamil Paral]

On Fri, Aug 3, 2018 at 12:24 AM, Kevin Fenzi  wrote:

> > I just don't think it's smart to drop the release number
> > thing and the fedora-repos-rawhide package.
>
> The number will keep working too. We can make that an alias in
> mirrormanager. So, for example if we had this implemented now and we
> branched 29 off, '29' would point to the branched release, '30' or
> 'rawhide' would point to rawhide.


To be fair here, if COPR and other third party inherited the "single repo
for all releases, using $releasever" approach as suggested, the number
would work for internal Fedora repos (because it's easy to do so in
mirrormanager), but it wouldn't work for COPR and other third-party repos
(because they don't have a mirrormanager). Of course they could make it
work by maintaining symlinks, just as now they can make it work by
maintaining symlink - but they don't.

The question is what is the important use case for using a number in repo
network requests, if we make it work by default (using releasever=rawhide).
Would anyone need to side-step dnf to perform their own calls, and this
would complicate the life for them? I don't know, tell me. (We could make
the releasever value easily obtainable in that case, either through dnf or
through evaluating an rpm macro).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HES4WBVWYYIPFL7AWEBLDI756NNGXMNY/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Kamil Paral]

On Thu, Aug 2, 2018 at 2:04 PM, Neal Gompa  wrote:

> This might surprise you, but I actually prefer the current way. It
> makes activating Rawhide an explicit action that can stay carried
> forward.


It's going to stay explicit and persistent, as explained by Kevin.


> This change makes no sense unless we were actually going to make
> Rawhide something that people could rely on.


I'm not sure if you're aware, but that's exactly what many people are
attempting to do. There are plans for automated gating in Rawhide. And
since I was one of those who were at least partially involved in this, I
proposed this change so that life is easier whenever you try to automate
stuff across releases, including Rawhide. I'm not saying it's a silver
bullet, and I hope I haven't missed any important use cases (hence this
discussion), but it should be one step closer to more consistency across
releases, therefore easier operation and automation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7JPWEEX5QBTALYEHDMWBT6GALYWF3NIG/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Kamil Paral]

On Thu, Aug 2, 2018 at 12:23 PM, Miroslav Suchý  wrote:

> Dne 31.7.2018 v 15:04 Kamil Paral napsal(a):
> > In short, package managers on Rawhide would no longer replace
> $releasever variable with a numerical value (like '29' at
> > this moment, soon '30'), but with 'rawhide' string instead. I hope this
> change will make life a bit easier for
> > third-party repos maintainers, for users, for developers and sysadmins,
> and for release engineering. The technical
> > implementation can be seen in the ticket (it's the 'Proposed solution
> 1'), together with a long discussion.
>
> Just note that fedora-rawhide.repo has:
> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
>
> Which now points to /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64 (on
> x86_64 machine).
>
> So either this file need to be renamed to RPM-GPG-KEY-fedora-rawhide-x86_64
> and updated on every branching or symlink
> need to be provided.
>

Interesting, this is something Kevin mentioned during the releng meeting,
which I didn't completely get:

17:09:15  also would fix a long standing issue around moving to
rawhide from a stable relase and gpg key...17:09:35  because
the gpg key file is called 'whatever-rawhide'  not 'whatever-29'


It seems he was mistaken then?

But yes, the files would have to be renamed, thanks for a reminder.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F2YBM3ILJZLJP6A33ZMEROCPKXYF6JMV/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Neal Gompa]

On Thu, Aug 2, 2018 at 7:12 PM Kevin Fenzi  wrote:
>
> On 08/02/2018 05:04 AM, Neal Gompa wrote:
>
> > This might surprise you, but I actually prefer the current way. It
> > makes activating Rawhide an explicit action that can stay carried
> > forward.
>
> The same for the proposed change, once you install fedora-release from
> rawhide you are on rawhide until and unless you intentionally switch.
>
> >The other thing is, realistically, few third party folks try
> > to build for Rawhide because Rawhide snapshots are either too old or
> > too broken.
> >
> > Case in point, the Docker containers for Rawhide effectively look like
> > Fedora 28, so what's the point? And upgrading to the latest released
> > compose just breaks everything, so it's not useful there either.
>
> I've been looking into this the last week or so by chance. Rawhide does
> compose containers every day with rawhide compose, they are just not
> correctly uploading to our registry. Hopefully this will be fixed soon.
>
> I don't think the answer to something being old or broken is to sigh and
> wander off. We need to fix those things, and I think we are making
> progress on doing so.
>
> > This change makes no sense unless we were actually going to make
> > Rawhide something that people could rely on. And I'm not sure that's a
> > good idea, since we have a nice cadence of releasing every 6
> > months(-ish). It's already too hard to keep Rawhide working because of
> > GCC breakages and the DNF stack work, and upstreams rely on our
> > Rawhide tree to suss out these kinds of things.
>
> I'm not sure I follow here... you don't think we should make rawhide
> something to rely on because we have regular releases?
>

I'm saying that if we try to pull off something similar to openSUSE
Tumbleweed with our current infrastructure and tooling, upstreams like
GCC and glibc could no longer leverage our Rawhide to validate their
code.

> In any case I think rawhide is very useful and without it our stable
> releases would be vastly more diffcult. We can definitely do better to
> make it stable, but I think it's quite usable.

It's not usable whenever we have compiler transitions or add more
weird GCC plugins, and that's something I've accepted will never
change as long as we're the distribution that helps make GCC great.
And that's fine.

> >
> > And I would argue that special casing Rawhide is sort of the point,
> > but I have no objection to making dnf --releasever=rawhide distro-sync
> > also work. I just don't think it's smart to drop the release number
> > thing and the fedora-repos-rawhide package.
>
> The number will keep working too. We can make that an alias in
> mirrormanager. So, for example if we had this implemented now and we
> branched 29 off, '29' would point to the branched release, '30' or
> 'rawhide' would point to rawhide. If you installed fedora-release from
> rawhide it would keep you on rawhide, if you install from branched or
> distro-sync to the branched fedora-release (by doing a 'dnf
> --releasever=29 distro-sync fedora-release') you go on branched. This
> means you don't need to worry about fedora-release-rawhide and
> enabling/disabling repos, and makes everyone's life easier.
>

But the problem is that it does make things slightly harder. And
you're not quite correct about this. The way that DNF gets this value
is through identifying the package that provides "system-release" or
"distribution-release" and identifies the version set for the package.
That version is what propagates to set $releasever. Hilariously,
PackageKit independently reads VERSION_ID from os-release(5) to
determine this. These don't always agree. And in addition, it's
impossible to stay on Rawhide through PackageKit without the controls
through fedora-repos-rawhide forcing it.

And how do you propose people sync down from Rawhide to "branched"? Or
sync up from an old Rawhide to "branched"/"stable" which this change?
From what I can tell, that wouldn't be easy.


--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MQQFHZNTJS4AZ6Y52264LXNGOOHJBAO4/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Kevin Fenzi]

On 08/02/2018 05:04 AM, Neal Gompa wrote:

> This might surprise you, but I actually prefer the current way. It
> makes activating Rawhide an explicit action that can stay carried
> forward. 

The same for the proposed change, once you install fedora-release from
rawhide you are on rawhide until and unless you intentionally switch.

>The other thing is, realistically, few third party folks try
> to build for Rawhide because Rawhide snapshots are either too old or
> too broken.
> 
> Case in point, the Docker containers for Rawhide effectively look like
> Fedora 28, so what's the point? And upgrading to the latest released
> compose just breaks everything, so it's not useful there either.

I've been looking into this the last week or so by chance. Rawhide does
compose containers every day with rawhide compose, they are just not
correctly uploading to our registry. Hopefully this will be fixed soon.

I don't think the answer to something being old or broken is to sigh and
wander off. We need to fix those things, and I think we are making
progress on doing so.

> This change makes no sense unless we were actually going to make
> Rawhide something that people could rely on. And I'm not sure that's a
> good idea, since we have a nice cadence of releasing every 6
> months(-ish). It's already too hard to keep Rawhide working because of
> GCC breakages and the DNF stack work, and upstreams rely on our
> Rawhide tree to suss out these kinds of things.

I'm not sure I follow here... you don't think we should make rawhide
something to rely on because we have regular releases?

In any case I think rawhide is very useful and without it our stable
releases would be vastly more diffcult. We can definitely do better to
make it stable, but I think it's quite usable.
> 
> And I would argue that special casing Rawhide is sort of the point,
> but I have no objection to making dnf --releasever=rawhide distro-sync
> also work. I just don't think it's smart to drop the release number
> thing and the fedora-repos-rawhide package.

The number will keep working too. We can make that an alias in
mirrormanager. So, for example if we had this implemented now and we
branched 29 off, '29' would point to the branched release, '30' or
'rawhide' would point to rawhide. If you installed fedora-release from
rawhide it would keep you on rawhide, if you install from branched or
distro-sync to the branched fedora-release (by doing a 'dnf
--releasever=29 distro-sync fedora-release') you go on branched. This
means you don't need to worry about fedora-release-rawhide and
enabling/disabling repos, and makes everyone's life easier.

kevin





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VVELN7R5O6FA2NVITNNTEF356H4E223I/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Michal Novotny]

On Thu, Aug 2, 2018 at 2:07 PM Neal Gompa  wrote:

> On Tue, Jul 31, 2018 at 9:59 AM Kamil Paral  wrote:
> >
> > Hello devel list,
> >
> > this is a request for comments for a recent proposal I filed at releng
> tracker:
> > https://pagure.io/releng/issue/7445
> >
> > In short, package managers on Rawhide would no longer replace
> $releasever variable with a numerical value (like '29' at this moment, soon
> '30'), but with 'rawhide' string instead. I hope this change will make life
> a bit easier for third-party repos maintainers, for users, for developers
> and sysadmins, and for release engineering. The technical implementation
> can be seen in the ticket (it's the 'Proposed solution 1'), together with a
> long discussion.
> >
> > To provide a longer explanation of the improvements I expect this to
> bring:
> > * Third-party repo maintainers will no longer need to provide two
> different repo files, one for stable Fedora releases using $releasever in
> URLs, and one for Rawhide hardcoding 'rawhide/' in URL and avoiding
> $releasever in URL. (Technically, two repo files are not needed if you
> always use a numbered dir even for Rawhide, but that's maintenance-heavy,
> because you need to change the directory number precisely at Branching
> time). This involves COPR as well.
> > * Users will be able to run commands like "dnf ... --releasever=28" even
> on Rawhide. That doesn't work at the moment, because most repo files don't
> use $releasever and instead have 'rawhide/' hardcoded.
> > * Developers and sysadmins will be able to use the same approach
> regarding repositories for stable Fedora releases and Rawhide. Rawhide will
> no longer be different, requiring special treatment. For example, the same
> repo URL can be used to install a system, or the same URL can be used to
> add an additional repository to an existing system. As an engineer working
> on automation, I was always annoyed how I need to special-case Rawhide
> everywhere (and of course, maintain a config file that states which release
> number Rawhide currently maps to). That will hopefully be no longer
> necessary, or very much reduced.
> > * Fedora release engineers should be able to get rid of
> fedora-repos-rawhide (again, hardcoding 'rawhide/' in URL), and use the
> standard repo files instead (making use of $releasever).
> >
> > There might be other advantages, which I haven't tested or though of.
> >
> > There are also disadvantages. The only one I know of at this moment, is
> that PackageKit is currently incompatible with this change (it uses custom
> logic for populating $releasever, different from dnf logic) and will need
> adjustments.
> >
> > Fedora releng has pre-approved this change in the ticket, and the point
> of this email is to ask for more feedback from all of you. I'd appreciate
> if you could help us identify edge cases we haven't thought of, or point
> out which tools would be incompatible with this change, so that we can
> track them and discuss it with their developers.
> >
>
> This might surprise you, but I actually prefer the current way. It
> makes activating Rawhide an explicit action that can stay carried
> forward. The other thing is, realistically, few third party folks try
> to build for Rawhide because Rawhide snapshots are either too old or
> too broken.
>
> Case in point, the Docker containers for Rawhide effectively look like
> Fedora 28, so what's the point? And upgrading to the latest released
> compose just breaks everything, so it's not useful there either.
>
> This change makes no sense unless we were actually going to make
> Rawhide something that people could rely on. And I'm not sure that's a
> good idea, since we have a nice cadence of releasing every 6
> months(-ish). It's already too hard to keep Rawhide working because of
> GCC breakages and the DNF stack work, and upstreams rely on our
> Rawhide tree to suss out these kinds of things.
>

If we can make rawhide something that people can rely on,
the actual releases will benefit from it as well.


>
> And I would argue that special casing Rawhide is sort of the point,
> but I have no objection to making dnf --releasever=rawhide distro-sync
> also work. I just don't think it's smart to drop the release number
> thing and the fedora-repos-rawhide package.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XGMTZTWR2QYDNSCONEPS4RR567DELMDT/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: RFC: make $releasever return "rawhide" on Rawhide

[Neal Gompa]

On Tue, Jul 31, 2018 at 9:59 AM Kamil Paral  wrote:
>
> Hello devel list,
>
> this is a request for comments for a recent proposal I filed at releng 
> tracker:
> https://pagure.io/releng/issue/7445
>
> In short, package managers on Rawhide would no longer replace $releasever 
> variable with a numerical value (like '29' at this moment, soon '30'), but 
> with 'rawhide' string instead. I hope this change will make life a bit easier 
> for third-party repos maintainers, for users, for developers and sysadmins, 
> and for release engineering. The technical implementation can be seen in the 
> ticket (it's the 'Proposed solution 1'), together with a long discussion.
>
> To provide a longer explanation of the improvements I expect this to bring:
> * Third-party repo maintainers will no longer need to provide two different 
> repo files, one for stable Fedora releases using $releasever in URLs, and one 
> for Rawhide hardcoding 'rawhide/' in URL and avoiding $releasever in URL. 
> (Technically, two repo files are not needed if you always use a numbered dir 
> even for Rawhide, but that's maintenance-heavy, because you need to change 
> the directory number precisely at Branching time). This involves COPR as well.
> * Users will be able to run commands like "dnf ... --releasever=28" even on 
> Rawhide. That doesn't work at the moment, because most repo files don't use 
> $releasever and instead have 'rawhide/' hardcoded.
> * Developers and sysadmins will be able to use the same approach regarding 
> repositories for stable Fedora releases and Rawhide. Rawhide will no longer 
> be different, requiring special treatment. For example, the same repo URL can 
> be used to install a system, or the same URL can be used to add an additional 
> repository to an existing system. As an engineer working on automation, I was 
> always annoyed how I need to special-case Rawhide everywhere (and of course, 
> maintain a config file that states which release number Rawhide currently 
> maps to). That will hopefully be no longer necessary, or very much reduced.
> * Fedora release engineers should be able to get rid of fedora-repos-rawhide 
> (again, hardcoding 'rawhide/' in URL), and use the standard repo files 
> instead (making use of $releasever).
>
> There might be other advantages, which I haven't tested or though of.
>
> There are also disadvantages. The only one I know of at this moment, is that 
> PackageKit is currently incompatible with this change (it uses custom logic 
> for populating $releasever, different from dnf logic) and will need 
> adjustments.
>
> Fedora releng has pre-approved this change in the ticket, and the point of 
> this email is to ask for more feedback from all of you. I'd appreciate if you 
> could help us identify edge cases we haven't thought of, or point out which 
> tools would be incompatible with this change, so that we can track them and 
> discuss it with their developers.
>

This might surprise you, but I actually prefer the current way. It
makes activating Rawhide an explicit action that can stay carried
forward. The other thing is, realistically, few third party folks try
to build for Rawhide because Rawhide snapshots are either too old or
too broken.

Case in point, the Docker containers for Rawhide effectively look like
Fedora 28, so what's the point? And upgrading to the latest released
compose just breaks everything, so it's not useful there either.

This change makes no sense unless we were actually going to make
Rawhide something that people could rely on. And I'm not sure that's a
good idea, since we have a nice cadence of releasing every 6
months(-ish). It's already too hard to keep Rawhide working because of
GCC breakages and the DNF stack work, and upstreams rely on our
Rawhide tree to suss out these kinds of things.

And I would argue that special casing Rawhide is sort of the point,
but I have no objection to making dnf --releasever=rawhide distro-sync
also work. I just don't think it's smart to drop the release number
thing and the fedora-repos-rawhide package.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XGMTZTWR2QYDNSCONEPS4RR567DELMDT/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Miroslav Suchý]

Dne 31.7.2018 v 15:04 Kamil Paral napsal(a):
> In short, package managers on Rawhide would no longer replace $releasever 
> variable with a numerical value (like '29' at
> this moment, soon '30'), but with 'rawhide' string instead. I hope this 
> change will make life a bit easier for
> third-party repos maintainers, for users, for developers and sysadmins, and 
> for release engineering. The technical
> implementation can be seen in the ticket (it's the 'Proposed solution 1'), 
> together with a long discussion.

Just note that fedora-rawhide.repo has:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch

Which now points to /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64 (on x86_64 
machine).

So either this file need to be renamed to RPM-GPG-KEY-fedora-rawhide-x86_64 and 
updated on every branching or symlink
need to be provided.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/U6TACYNXEINUFHGNHIHGPAZRM2Q5J6CD/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Vít Ondruch]

Dne 1.8.2018 v 13:09 Kamil Paral napsal(a):
> On Wed, Aug 1, 2018 at 10:36 AM, Vít Ondruch  > wrote:
>
> I'm somehow missing the point probably, but as a rawhide user,
> when I want to take some package from F28 (typically kernel), then
> I have to do "sudo dnf update --disablerepo=*
> --enablerepo=updates{,-testing} kernel\* --release 28", i.e. the
> problem is that I have to enable the "updates" repositories and
> that is about organization of the packages, not about the 28 vs
> Rawhide. So how would your proposal help with this?
>
>
> The current situation is that 'fedora', 'updates' and
> 'updates-testing' repos are disabled in Rawhide, and instead a single
> 'rawhide' repo is enabled (with hardcoded paths). It's true that if
> you specifically disable the rawhide repo and instead enable the
> fedora/updates/updates-testing ones (note: you're missing the fedora
> repo in your example)

Obviously I am not enabling "fedora" repo, because it is too old. But
now I see what you are talking about. I should have enabled "fedora"
repo all the time and it should work the same way for f28 as for the
rawhide. This would make the life easier indeed.


V.


> , the command does work. But it's again one example of what you need
> to do differently on Rawhide than on other releases. I'd like to see
> the same approach wherever you are.
>
> With the new approach, you could do simply this:
> $ dnf list/download/repoquery/whatever package --releasever=28
> the same way as you do this on other releases.
>
> Now, there are two ways how this can be handled by Fedora releng.
> Either they only enable the 'fedora' repo on Rawhide, and then if you
> wanted to access updates/updates-testing repos with this command line,
> you'd need to add --enablerepo=updates and/or
> --enablerepo=updates-testing. (You can say that this is still
> consistent with stable releases, it's just that the general
> expectation is that 'updates' repo is always enabled). Or they enable
> 'updates' repo by default on Rawhide as well (the same way stable
> releases have it), and they point it to an empty repo dir (they can
> even set it to never expire or almost never). In that case no
> --enablerepo will be necessary, and this will be 100% matching stable
> releases approach.
>
> I admit the end-user benefit here is very small (except for
> consistency and perhaps documentation). When you start automating
> tasks and need to run such commands on different Fedora releases
> including Rawhide, the benefit might be larger.
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7KUNFZHFPDEK4OH5OJ4GWJXJPMSFTBNZ/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6KICTGT3R4NDW5XMBK5CVTXNYD375SAD/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Kamil Paral]

On Wed, Aug 1, 2018 at 10:36 AM, Vít Ondruch  wrote:

> I'm somehow missing the point probably, but as a rawhide user, when I want
> to take some package from F28 (typically kernel), then I have to do "sudo
> dnf update --disablerepo=* --enablerepo=updates{,-testing} kernel\*
> --release 28", i.e. the problem is that I have to enable the "updates"
> repositories and that is about organization of the packages, not about the
> 28 vs Rawhide. So how would your proposal help with this?
>

The current situation is that 'fedora', 'updates' and 'updates-testing'
repos are disabled in Rawhide, and instead a single 'rawhide' repo is
enabled (with hardcoded paths). It's true that if you specifically disable
the rawhide repo and instead enable the fedora/updates/updates-testing ones
(note: you're missing the fedora repo in your example), the command does
work. But it's again one example of what you need to do differently on
Rawhide than on other releases. I'd like to see the same approach wherever
you are.

With the new approach, you could do simply this:
$ dnf list/download/repoquery/whatever package --releasever=28
the same way as you do this on other releases.

Now, there are two ways how this can be handled by Fedora releng. Either
they only enable the 'fedora' repo on Rawhide, and then if you wanted to
access updates/updates-testing repos with this command line, you'd need to
add --enablerepo=updates and/or --enablerepo=updates-testing. (You can say
that this is still consistent with stable releases, it's just that the
general expectation is that 'updates' repo is always enabled). Or they
enable 'updates' repo by default on Rawhide as well (the same way stable
releases have it), and they point it to an empty repo dir (they can even
set it to never expire or almost never). In that case no --enablerepo will
be necessary, and this will be 100% matching stable releases approach.

I admit the end-user benefit here is very small (except for consistency and
perhaps documentation). When you start automating tasks and need to run
such commands on different Fedora releases including Rawhide, the benefit
might be larger.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7KUNFZHFPDEK4OH5OJ4GWJXJPMSFTBNZ/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Vít Ondruch]

I'm somehow missing the point probably, but as a rawhide user, when I
want to take some package from F28 (typically kernel), then I have to do
"sudo dnf update --disablerepo=* --enablerepo=updates{,-testing}
kernel\* --release 28", i.e. the problem is that I have to enable the
"updates" repositories and that is about organization of the packages,
not about the 28 vs Rawhide. So how would your proposal help with this?


V.


Dne 31.7.2018 v 15:04 Kamil Paral napsal(a):
> Hello devel list,
>
> this is a request for comments for a recent proposal I filed at releng
> tracker:
> https://pagure.io/releng/issue/7445
>
> In short, package managers on Rawhide would no longer replace
> $releasever variable with a numerical value (like '29' at this moment,
> soon '30'), but with 'rawhide' string instead. I hope this change will
> make life a bit easier for third-party repos maintainers, for users,
> for developers and sysadmins, and for release engineering. The
> technical implementation can be seen in the ticket (it's the 'Proposed
> solution 1'), together with a long discussion.
>
> To provide a longer explanation of the improvements I expect this to
> bring:
> * Third-party repo maintainers will no longer need to provide two
> different repo files, one for stable Fedora releases using $releasever
> in URLs, and one for Rawhide hardcoding 'rawhide/' in URL and avoiding
> $releasever in URL. (Technically, two repo files are not needed if you
> always use a numbered dir even for Rawhide, but that's
> maintenance-heavy, because you need to change the directory number
> precisely at Branching time). This involves COPR as well. 
> * Users will be able to run commands like "dnf ... --releasever=28"
> even on Rawhide. That doesn't work at the moment, because most repo
> files don't use $releasever and instead have 'rawhide/' hardcoded.
> * Developers and sysadmins will be able to use the same approach
> regarding repositories for stable Fedora releases and Rawhide. Rawhide
> will no longer be different, requiring special treatment. For example,
> the same repo URL can be used to install a system, or the same URL can
> be used to add an additional repository to an existing system. As an
> engineer working on automation, I was always annoyed how I need to
> special-case Rawhide everywhere (and of course, maintain a config file
> that states which release number Rawhide currently maps to). That will
> hopefully be no longer necessary, or very much reduced.
> * Fedora release engineers should be able to get rid of
> fedora-repos-rawhide (again, hardcoding 'rawhide/' in URL), and use
> the standard repo files instead (making use of $releasever).
>
> There might be other advantages, which I haven't tested or though of.
>
> There are also disadvantages. The only one I know of at this moment,
> is that PackageKit is currently incompatible with this change (it uses
> custom logic for populating $releasever, different from dnf logic) and
> will need adjustments.
>
> Fedora releng has pre-approved this change in the ticket, and the
> point of this email is to ask for more feedback from all of you. I'd
> appreciate if you could help us identify edge cases we haven't thought
> of, or point out which tools would be incompatible with this change,
> so that we can track them and discuss it with their developers.
>
> Thanks,
> Kamil
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5UVGSBRLX352A4S2CBZ2CGBXPAGQTYKB/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUJUEHMKDFAYZCBNK6BRY72ZNQ4EHWAE/

RFC: make $releasever return "rawhide" on Rawhide

[Kamil Paral]

Hello devel list,

this is a request for comments for a recent proposal I filed at releng
tracker:
https://pagure.io/releng/issue/7445

In short, package managers on Rawhide would no longer replace $releasever
variable with a numerical value (like '29' at this moment, soon '30'), but
with 'rawhide' string instead. I hope this change will make life a bit
easier for third-party repos maintainers, for users, for developers and
sysadmins, and for release engineering. The technical implementation can be
seen in the ticket (it's the 'Proposed solution 1'), together with a long
discussion.

To provide a longer explanation of the improvements I expect this to bring:
* Third-party repo maintainers will no longer need to provide two different
repo files, one for stable Fedora releases using $releasever in URLs, and
one for Rawhide hardcoding 'rawhide/' in URL and avoiding $releasever in
URL. (Technically, two repo files are not needed if you always use a
numbered dir even for Rawhide, but that's maintenance-heavy, because you
need to change the directory number precisely at Branching time). This
involves COPR as well.
* Users will be able to run commands like "dnf ... --releasever=28" even on
Rawhide. That doesn't work at the moment, because most repo files don't use
$releasever and instead have 'rawhide/' hardcoded.
* Developers and sysadmins will be able to use the same approach regarding
repositories for stable Fedora releases and Rawhide. Rawhide will no longer
be different, requiring special treatment. For example, the same repo URL
can be used to install a system, or the same URL can be used to add an
additional repository to an existing system. As an engineer working on
automation, I was always annoyed how I need to special-case Rawhide
everywhere (and of course, maintain a config file that states which release
number Rawhide currently maps to). That will hopefully be no longer
necessary, or very much reduced.
* Fedora release engineers should be able to get rid of
fedora-repos-rawhide (again, hardcoding 'rawhide/' in URL), and use the
standard repo files instead (making use of $releasever).

There might be other advantages, which I haven't tested or though of.

There are also disadvantages. The only one I know of at this moment, is
that PackageKit is currently incompatible with this change (it uses custom
logic for populating $releasever, different from dnf logic) and will need
adjustments.

Fedora releng has pre-approved this change in the ticket, and the point of
this email is to ask for more feedback from all of you. I'd appreciate if
you could help us identify edge cases we haven't thought of, or point out
which tools would be incompatible with this change, so that we can track
them and discuss it with their developers.

Thanks,
Kamil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5UVGSBRLX352A4S2CBZ2CGBXPAGQTYKB/