Re: Fedora Modularity: What's the Problem?
Stephen Gallagher wrote: > One of the recurring themes in the ongoing Modularity threads has been > that we've made references to the problems we're trying to solve, but we > haven't done a good job of gathering those requirements and use-cases into > a single place. To resolve this, I've written a (fairly long) blog post > describing the set of problems that we are trying to solve. Unfortunately, the list of requirements is very long (IMHO, unreasonably long), and some of the requirements are in conflict, as I am going to explain point by point below. For some of the requirements, it is also arguable whether they are really relevant, especially for Fedora. I am also going to address those individually below. I would also like to point out that none of the requirements you listed actually require default streams, only modules for alternate versions (and perhaps not even those), and that in fact the first requirement under "Critical use cases for consumers" (that simplicity for users should trump simplicity for packagers) is actually an argument against default streams. > Please note as well that these are goals. There are numerous places where > the implementation of Modularity at the time of this writing is not yet > fully adherent to them. Unfortunately, there are some requirements in your list that are mutually exclusive (see below), so the implementation will never be fully adherent to them, and in fact no implementation will. So some requirements will have to go. > This is excellent for the maintainers of the distribution, because it > allows them to test that everything works together as a cohesive whole. It > means that there’s one authoritative version to align to. > > Users, on the other hand, are most concerned about solving their problem. > It matters less to them that the distribution is cohesive and more that > the tools they need are available to them. It actually matters to users that the distribution is cohesive because they want to use more than just one application, and those applications need to work together. And this is the area where the design restrictions of Modularity come into play. > The “Too Fast/Too Slow” problem is basically this: users want a solid, > stable, reliable, *unchanging* system. They want it to stay that way for > the life of their application. However, they also want their application > to run using the set of dependencies it was designed for. Do they really? I want my applications to run using the dependencies that are part of the distribution platform (and which, as a result, do not conflict with other applications I may also want to install). If those dependencies are too new, the application needs to be ported to the new versions. If they are too old, then they probably need to be updated systemwide (assuming the newer version is backwards-compatible, of course), as has been done with Qt more than once. Where that is not possible, the next best solution is to have a parallel- installable compatibility library that provides the version required by the application. The existing packaging guidelines for compatibility libraries cover those pretty well: suffixed package name, the runtime packages must not conflict (ever), the -devel packages should not conflict if it can be avoided. I do not care whether the library version is the exact version upstream happened to have installed. It just needs to make the application work. And I consider this making things work together with shared dependencies to be the one value added by the distribution over the upstream software, i.e., the distribution's entire purpose. > If that doesn’t happen to be the same version (newer or older) as the one > selected for the monolithic distribution, the user will now have to resort > to alternative means to get up and running. This may be as simple as > bundling a dependency or as drastic as selecting an entirely different > distribution that better fits their specific need. However, Modularity does not provide a reasonable way to bundle dependencies (that is not already possible in ursine RPMs), because as Zbigniew pointed out, the bundled dependencies are never really private, but still pollute both the package name namespace and the file system, conflicting with any other version (ursine or from another module) of the same package. The only way to prevent these conflicts is to resort to RPM-level conflict- free bundling techniques such as static linking or the aforementioned compatibility package pattern. But then you do not need Modularity to begin with. > A few years back, the Product Management team inside Red Hat performed a > large-scale survey of customers and potential customers about the user > experience of Red Hat Enterprise Linux. In particular, they asked about > their level of satisfaction with the software available from the > enterprise distribution and their opinion on these Software Collections. > > Perhaps unsurprisin
Re: ask.fedoraproject.org - redirects?
On Sun, 3 Nov 2019 at 14:29, Miro Hrončok wrote: > > On 03. 11. 19 20:24, Miro Hrončok wrote: > > Hero maintenance > > I don't normally correct my typos on mailing lists to avoid further e-mails, > but > this one is particularly bad. I meant "zero" of course. Sorry about that. > I was going for Freudian slip because it is going to take that to do that work. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ask.fedoraproject.org - redirects?
Stephen John Smoogen wrote: > I do not disagree with you on this. I also know we don't have a larger > number of system administrators, servers and time to do all the things > many community members 'expect a project to have'. We have the > resources to do one set of things excellently, two well, and three or > more poorly. The problem is that everyone seems to want 3 or more > things from us which combinatoric-ally end up being massive. We can > either not offer those items, outsource them, or do them poorly and > shut it down like everything from asterisk to various previous forum > attempts. > > I personally would prefer if the world stopped moving to the 'the next > big social thing' every 6 months which needs all new tooling and > setup.. but I have also learned that hasn't happened in 4000 years... IMHO, it was a mistake to bring up ask.fedoraproject.org to begin with. We do not have the resources to maintain it (hence the outsourcing), and it is yet another communication platform that is fragmenting the community. We already had mailing lists and forums (i.e., already one platform too many). I do not see what ask.fedoraproject.org allows that was not already possible with those two existing platforms. Jumping on the hype of the day "every 6 months" is just not a reasonable thing to do. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Trouble with install ordering and SELinux config
On 11/3/19 11:17 AM, Todd Zullinger wrote:
Dridi Boukelmoune wrote:
On Sat, Nov 2, 2019 at 2:21 AM Orion Poplawski wrote:
On 11/1/19 1:47 PM, Daniel Walsh wrote:
Flat pack should be doing a requires(post): selinux-policy-base
To make sure it is installed before flatpack.
Thanks. The proper incantation actually though seems to be:
%{?selinux_requires}
which contains that. See:
https://fedoraproject.org/wiki/SELinux/IndependentPolicy#The_Preamble
I have used this successfully for EPEL 7 work at $DAYJOB and woud have
pointed this out earlier if I hadn't fallen off the devel list for the
past few weeks.
Revisiting this on Fedora 31 I still see this:
$ rpm --eval %selinux_requires | grep git
BuildRequires: git
And I can't help but wonder whether we really need git at build time
as this slows down the build root creation step.
Any idea from SELinux folks?
If it does turn out to be needed, I git-core may be a better
requirement than git. The former avoids pulling in the perl
stack, among other things.
Well, as it stands since selinux-policy (which defines
%selinux_requires) is not currently in the buildroot, none of the BRs in
%selinux_requires are actually applied.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ask.fedoraproject.org - redirects?
On 03. 11. 19 20:24, Miro Hrončok wrote: Hero maintenance I don't normally correct my typos on mailing lists to avoid further e-mails, but this one is particularly bad. I meant "zero" of course. Sorry about that. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ask.fedoraproject.org - redirects?
On 03. 11. 19 16:50, Stephen John Smoogen wrote: On Sun, 3 Nov 2019 at 05:33, Miro Hrončok wrote: IMHO It should give the useres the new full link. If that would not be possible, maybe it could read: "Oh no, this page is not here. Try replacing ask.fedoraproject.org with askbot.fedoraproject.org to get archived content of this page." I think that the problem is that askbot archives will be going away in a couple of weeks. That would indeed be a big loss. Would it help if I freeze them as HTML and publish them trough github pages or similar? Hero maintenance, just occasional DNS change. I've actually done this before: https://askfit.cz https://github.com/hroncok/askfit-static -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Official font
Le mercredi 30 octobre 2019 à 12:53 -0400, Stephen John Smoogen a écrit : > On Wed, 30 Oct 2019 at 11:59, Iñaki Ucar > wrote: > > Hi all, > > > > I incidentally discovered today that, since quite recently, there's > > a > > Red Hat font [1]. And this led me to think about the popularity of > > the > > Ubuntu font, you know, and how nice would be to have a nice catchy > > official Fedora font integrated into the distro... I'm just > > thinking > > aloud, because I don't know anything about font design. But maybe > > someone picks up the gauntlet... ;-) > > > > Font designs are hard. You have multiple copyright and similar legal > rights which you have to both deal with and contract out to. Creating fonts is hard, because they require drawing many symbols to be useful (Unicode grows year after year), over several axes (at least Weight, Width and Slope), keeping all the symbols æsthetically balanced, and respecting cultural conventions. Plus, HiDPI is not yet available everywhere, so you need to deal with pixel grid-fitting (round symbol shape dimensions at all sizes) and all the associated crap. Last I checked Wayland is unable to drive HiDPI screens properly because input handling is not separated in a dedicated thread, so if you increase the number of pixels too much, input will lag and miss keystrokes. It is fairly easy to create toy fonts limited to a few hundreds of symbols (typically ASCII), or to create an “artistic” effect (meaning no one will suffer reading long runs of texts that use this font). It is mightily hard to create a font, good enough to be used in everyday life. That’s why most free software projects cheat and commission they fonts at professional foundries (Bitstream for Vera, Ascender for Liberation, Crosscore and Droid, Bold Monday for IBM Plex, Bigelow & Holmes for Go, Dalton Maag for Ubuntu). There are very few quality fonts on the market which have been created by a community process (Linux Libertine, DejaVu, Cantarell) > > Font work > > comes up in waves.. the last wave was about 6 to 8 years ago when > > people were working on various fonts for Fedora.. but then it sort > of > > hit a fallow time because it takes a continual effort of interested > > and knowledgeable participants. Font work (creation and packaging) takes a lot of commitment and attention to detail. It's hard to sustain so it comes and goes. BTW https://pagure.io/fork/nim/fonts-rpm-macros/commits/master https://pagure.io/fork/nim/packaging-committee/tree/fonts-rpm-macros (rebases hide the actual commit dates in the web view) Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ask.fedoraproject.org - redirects?
On Sun, 3 Nov 2019 at 12:50, Kevin Kofler wrote: > > Stephen John Smoogen wrote: > > These systems are not small tasks to keep up and running.. the > > upstream code is not 'static' or backportable so you are constantly > > updating to upstream to keep up with CVE security. There are also > > regular schema changes and a ton of packaging items which need someone > > who is going to become a discourse expert to run. Our experience has > > been that we either end up having a system which is broken a lot > > because it isn't being maintained or is taking up so much time that > > Fedora people complain we aren't working on getting a compose out the > > door. > > > > So instead we decided to invest money into a company which pays the > > authors of discourse (and we previously paid the person who wrote > > askbot). That means we do lose absolute control but we do fund the > > upstream. > > Yet, this means that we are experiencing exactly the kind of lock-in that we > claim to free us and our users from. > > Having to pay extra for some features (as the hosted version of Discourse > does it) is lock-in. (Interestingly, unlike, e.g., Gitlab, Discourse > apparently does not follow this same crippleware strategy for the self- > hosted version, they state that all features are provided as Free (Libre) > Software and at no cost (if you self-host the application). Only the hosted > version of Discourse does market segmentation.) > > Having no way to migrate the data when switching to a different platform is > lock-in, too. I do not disagree with you on this. I also know we don't have a larger number of system administrators, servers and time to do all the things many community members 'expect a project to have'. We have the resources to do one set of things excellently, two well, and three or more poorly. The problem is that everyone seems to want 3 or more things from us which combinatoric-ally end up being massive. We can either not offer those items, outsource them, or do them poorly and shut it down like everything from asterisk to various previous forum attempts. I personally would prefer if the world stopped moving to the 'the next big social thing' every 6 months which needs all new tooling and setup.. but I have also learned that hasn't happened in 4000 years... -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Trouble with install ordering and SELinux config
Dridi Boukelmoune wrote:
> On Sat, Nov 2, 2019 at 2:21 AM Orion Poplawski wrote:
>>
>> On 11/1/19 1:47 PM, Daniel Walsh wrote:
>>> Flat pack should be doing a requires(post): selinux-policy-base
>>>
>>> To make sure it is installed before flatpack.
>>
>> Thanks. The proper incantation actually though seems to be:
>>
>> %{?selinux_requires}
>>
>> which contains that. See:
>>
>> https://fedoraproject.org/wiki/SELinux/IndependentPolicy#The_Preamble
>
> I have used this successfully for EPEL 7 work at $DAYJOB and woud have
> pointed this out earlier if I hadn't fallen off the devel list for the
> past few weeks.
>
> Revisiting this on Fedora 31 I still see this:
>
> $ rpm --eval %selinux_requires | grep git
> BuildRequires: git
>
> And I can't help but wonder whether we really need git at build time
> as this slows down the build root creation step.
>
> Any idea from SELinux folks?
If it does turn out to be needed, I git-core may be a better
requirement than git. The former avoids pulling in the perl
stack, among other things.
--
Todd
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ask.fedoraproject.org - redirects?
Stephen John Smoogen wrote: > These systems are not small tasks to keep up and running.. the > upstream code is not 'static' or backportable so you are constantly > updating to upstream to keep up with CVE security. There are also > regular schema changes and a ton of packaging items which need someone > who is going to become a discourse expert to run. Our experience has > been that we either end up having a system which is broken a lot > because it isn't being maintained or is taking up so much time that > Fedora people complain we aren't working on getting a compose out the > door. > > So instead we decided to invest money into a company which pays the > authors of discourse (and we previously paid the person who wrote > askbot). That means we do lose absolute control but we do fund the > upstream. Yet, this means that we are experiencing exactly the kind of lock-in that we claim to free us and our users from. Having to pay extra for some features (as the hosted version of Discourse does it) is lock-in. (Interestingly, unlike, e.g., Gitlab, Discourse apparently does not follow this same crippleware strategy for the self- hosted version, they state that all features are provided as Free (Libre) Software and at no cost (if you self-host the application). Only the hosted version of Discourse does market segmentation.) Having no way to migrate the data when switching to a different platform is lock-in, too. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ask.fedoraproject.org - redirects?
On Sun, 3 Nov 2019 at 05:33, Miro Hrončok wrote: > IMHO It should give the useres the new full link. > > If that would not be possible, maybe it could read: > > "Oh no, this page is not here. Try replacing ask.fedoraproject.org with > askbot.fedoraproject.org to get archived content of this page." > I think that the problem is that askbot archives will be going away in a couple of weeks. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ask.fedoraproject.org - redirects?
On 02. 11. 19 9:23, Ankur Sinha wrote: On Sat, Nov 02, 2019 09:12:21 +0100, Miro Hrončok wrote: On 01. 11. 19 22:58, Tim Jackson wrote: I realise this is not exactly news, but when replacing Ask Fedora, was there a reason to break all the links on the entire web to existing solutions, rather than just putting the new system on a different domain? Or, failing that, at least adding (conditional) redirects and/or links to the "old" site? It seems like finally as Fedora was building up a body of useful "ask"-type content and get traction on search engines (= searching for things not only leading to results about Ubuntu), we wiped the slate clean. As it is now, whenever I (as a Fedora user) search for something, I still frequently end up at a dead end on a 404 page on ask.fedoraproject.org. There isn't even a *link* to the corresponding page on askbot.fedoraproject.org - surely that, at least, is something we could do? (yes, I realise one just has to add "bot" to the hostname, but that's not the point - not everyone will either realise that, or bother, and it's trivial to do when generating the error page) This is very much needed but apparently, the effort got stalled: https://pagure.io/fedora-websites/issue/953 https://ask.fedoraproject.org/t/updating-the-404-template-to-mention-the-move-to-discourse/407/6 It didn't stall, it was fixed long ago. The 404 page now says: "Welcome to the new AskFedora! Sorry, we couldn't find that page. If you are looking for the older platform, it is archived at askbot.fedoraproject.org. IMHO It should give the useres the new full link. If that would not be possible, maybe it could read: "Oh no, this page is not here. Try replacing ask.fedoraproject.org with askbot.fedoraproject.org to get archived content of this page." -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Trouble with install ordering and SELinux config
On Sat, Nov 2, 2019 at 2:21 AM Orion Poplawski wrote:
>
> On 11/1/19 1:47 PM, Daniel Walsh wrote:
> > Flat pack should be doing a requires(post): selinux-policy-base
> >
> > To make sure it is installed before flatpack.
>
> Thanks. The proper incantation actually though seems to be:
>
> %{?selinux_requires}
>
> which contains that. See:
>
> https://fedoraproject.org/wiki/SELinux/IndependentPolicy#The_Preamble
I have used this successfully for EPEL 7 work at $DAYJOB and woud have
pointed this out earlier if I hadn't fallen off the devel list for the
past few weeks.
Revisiting this on Fedora 31 I still see this:
$ rpm --eval %selinux_requires | grep git
BuildRequires: git
And I can't help but wonder whether we really need git at build time
as this slows down the build root creation step.
Any idea from SELinux folks?
Thanks,
Dridi
> This works because the selinux-policy-base providing packages have a:
>
> Requires(pre): selinux-policy
>
> which pushes that earlier. I'm still not entirely convinced that that
> creates a contract that selinux-policy's %post script will be run before
> the flatpak-selinux's %post script, but hopefully in practice it won't
> matter.
>
> I've created https://src.fedoraproject.org/rpms/flatpak/pull-request/5
>
> > On 11/1/19 2:51 PM, Tim Zabel wrote:
> >> On Fri, 2019-11-01 at 12:02 -0600, Orion Poplawski wrote:
> >>> My F31 kickstart install is failing with:
> >>>
> >>> DNF error: Error in POSTIN scriptlet in rpm package flatpak-selinux
> >> Hmm, I've also ran into this issue of flatpak-selinux's POSTIN failing
> >> :(
> >>
> >> Just to be sure, are you building the kickstart with SELinux set to
> >> permissive? It won't work if it's in Enforcing.
> >>
> >>> This is because flapak-selinux installs a SELinux module in %post:
> >>>
> >>> %post selinux
> >>> %selinux_modules_install %{_datadir}/selinux/packages/flatpak.pp.bz2
> >>>
> >>> which sources /etc/selinux/config. It is failing because
> >>> /etc/selinux/config
> >>> does not exist and /bin/sh exits with failure (/bin/bash does not
> >>> interestingly enough).
> >>>
> >>> This was reported earlier here:
> >>>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1723118
> >> For reference, here are some other BZs that I've ran into while trying
> >> to come up with my own fixes to this issue:
> >>
> >> *https://bugzilla.redhat.com/show_bug.cgi?id=1732132
> >>
> >> *https://bugzilla.redhat.com/show_bug.cgi?id=1665643
> >>
> >>
> >>> and the suggestion made to add:
> >>>
> >>> Requires(post): selinux-policy
> >>>
> >>> since selinux-policy owns /etc/selinux/config. However, selinux-
> >>> policy
> >>> creates /etc/selinux/config in its own %post, and Requires(post) only
> >>> guarantees that the package's contents are installed, not that its
> >>> scripts are
> >>> complete.
> >>>
> >>> So, what's the best way to fix this? We need /etc/selinux/policy to
> >>> be
> >>> present and populated with SELINUXTYPE=targeted for the selinux
> >>> policy modules
> >>> to be installed properly.
> >>>
> >>> selinux-policy does:
> >>>
> >>> %post
> >>> if [ ! -s /etc/selinux/config ]; then
> >>> #
> >>> # New install so we will default to targeted policy
> >>> #
> >>> echo "
> >>> # This file controls the state of SELinux on the system.
> >>> # SELINUX= can take one of these three values:
> >>> # enforcing - SELinux security policy is enforced.
> >>> # permissive - SELinux prints warnings instead of enforcing.
> >>> # disabled - No SELinux policy is loaded.
> >>> SELINUX=enforcing
> >>> # SELINUXTYPE= can take one of these three values:
> >>> # targeted - Targeted processes are protected,
> >>> # minimum - Modification of targeted policy. Only selected
> >>> processes are
> >>> protected.
> >>> # mls - Multi Level Security protection.
> >>> SELINUXTYPE=targeted
> >>>
> >>> " > /etc/selinux/config
> >>>
> >>> ln -sf ../selinux/config /etc/sysconfig/selinux
> >>> restorecon /etc/selinux/config 2> /dev/null || :
> >>> else
> >>> . /etc/selinux/config
> >>> fi
> >>> exit 0
> >>>
> >>> But can't this be achieved simply with:
> >>>
> >>> %config(noreplace) %{_sysconfdir}/selinux/config
> >>>
> >>> New installs would get the default config, but otherwise you would
> >>> get a
> >>> .rpmnew file.
> >>>
> >>> However, I realize that nothing is particularly simple about SELinux
> >>> so there
> >>> are probably things I'm not aware of that prevent this.
> >>>
> >>> PS - the else code seems to be a no-op.
> >> Back when I was trying to find my own fixes, I managed to fix one
> >> portion of the %post selinux that was enough to solve my own problems,
> >> but this issue you're seeing is one that I wasn't able to find a fix
> >> for myself. I've love to see a resolution to this.
> >>
> >> ___
> >> devel mailing list --devel@lists.fedoraproject.org
> >> To unsubscribe send an email todevel-le...@lists.fedoraproject.org
> >> Fedora Code of
> >> Cond
