Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Igor Gnatenko]

I must have just overlooked this.

And also, there is no automation, there are just regular expressions ;)

On Tue, Feb 5, 2019 at 5:02 PM Anderson, Charles R  wrote:

> Igor, your change broke my package.  Whatever automation you used should
> have taken into account that %post sections don't end until the next RPM
> directive.  %ifarch does not end a %post section.
>
> diff --git a/ocp.spec b/ocp.spec
> index 0d6fd28..2495ab5 100644
> --- a/ocp.spec
> +++ b/ocp.spec
> @@ -139,9 +139,6 @@ cp -p license-images.txt license-videos.txt
> %{buildroot}%{_pkgdocdir}
>  %{_datadir}/applications/*ocp.desktop
>  %config(noreplace) /etc/ocp.ini
>
> -%post
> -/sbin/install-info %{_infodir}/ocp.info.gz %{_infodir}/dir || :
> -
>  %ifarch %{ix86}
>  %if %{?_with_i386asm:1}%{!?_with_i386asm:0}
>  # This is the i386 assembly version.  We need to allow text relocations.
> @@ -162,11 +159,6 @@ restorecon -R %{_libdir}/ocp-* || :
>  %endif
>
>
> On Fri, Dec 21, 2018 at 09:25:13AM +0100, Igor Gnatenko wrote:
> > If I manage to get this approved and done before mass rebuild, I'll
> > just push changes without bumping anything. If it will happen
> > during/after mass rebuild, I'll also bump.
> >
> > I'm hoping to complete it before mass rebuild.
> >
> > On Thu, Dec 20, 2018 at 6:55 PM Kevin Fenzi  wrote:
> > >
> > > On 12/20/18 2:35 AM, Dominik 'Rathann' Mierzejewski wrote:
> > > > On Thursday, 20 December 2018 at 11:29, Richard Hughes wrote:
> > > >> On Thu, 20 Dec 2018 at 10:16, Hans de Goede 
> wrote:
> > > >>> So I say +100 to just pushing the changes directly, as said
> > > >>> people can always revert them.
> > > >>
> > > >> Completely agree. For my packages I'd totally prefer things just
> > > >> magically be done without any action on my part.
> > > >
> > > > Same here and I'm in ACLs for ~100 packages, too. I definitely don't
> > > > want to deal with a 100 PRs, for something so trivial. I'll revert
> > > > if necessary, no big deal. Thanks for doing this to Igor, by the way.
> > >
> > > Yes, thanks!
> > >
> > > However, some clarification: do you intend to just remove the
> scriptlets
> > > and thats it? Or, also bump version and add a changelog entry? or also
> > > that and do a build?
> > >
> > > I'm fine with any of those, but I guess builds could interfere with
> > > people who are in the middle of rebuilding some stacks.
> > >
> > > kevin
> > >
> > >
> > >
> > > ___
> > > 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
> > ___
> > 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
>
> --
> Charles R. Anderson, JNCIE-SP   c...@wpi.edu
> Network Architect   (508) 831-6110
> Network Operations - Morgan Hall(508) 831-
> Worcester Polytechnic Institute Fax (508) 831-6669
>
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Anderson, Charles R]

Igor, your change broke my package.  Whatever automation you used should have 
taken into account that %post sections don't end until the next RPM directive.  
%ifarch does not end a %post section.

diff --git a/ocp.spec b/ocp.spec
index 0d6fd28..2495ab5 100644
--- a/ocp.spec
+++ b/ocp.spec
@@ -139,9 +139,6 @@ cp -p license-images.txt license-videos.txt 
%{buildroot}%{_pkgdocdir}
 %{_datadir}/applications/*ocp.desktop
 %config(noreplace) /etc/ocp.ini
 
-%post
-/sbin/install-info %{_infodir}/ocp.info.gz %{_infodir}/dir || :
-
 %ifarch %{ix86}
 %if %{?_with_i386asm:1}%{!?_with_i386asm:0}
 # This is the i386 assembly version.  We need to allow text relocations.
@@ -162,11 +159,6 @@ restorecon -R %{_libdir}/ocp-* || :
 %endif
 

On Fri, Dec 21, 2018 at 09:25:13AM +0100, Igor Gnatenko wrote:
> If I manage to get this approved and done before mass rebuild, I'll
> just push changes without bumping anything. If it will happen
> during/after mass rebuild, I'll also bump.
> 
> I'm hoping to complete it before mass rebuild.
> 
> On Thu, Dec 20, 2018 at 6:55 PM Kevin Fenzi  wrote:
> >
> > On 12/20/18 2:35 AM, Dominik 'Rathann' Mierzejewski wrote:
> > > On Thursday, 20 December 2018 at 11:29, Richard Hughes wrote:
> > >> On Thu, 20 Dec 2018 at 10:16, Hans de Goede  wrote:
> > >>> So I say +100 to just pushing the changes directly, as said
> > >>> people can always revert them.
> > >>
> > >> Completely agree. For my packages I'd totally prefer things just
> > >> magically be done without any action on my part.
> > >
> > > Same here and I'm in ACLs for ~100 packages, too. I definitely don't
> > > want to deal with a 100 PRs, for something so trivial. I'll revert
> > > if necessary, no big deal. Thanks for doing this to Igor, by the way.
> >
> > Yes, thanks!
> >
> > However, some clarification: do you intend to just remove the scriptlets
> > and thats it? Or, also bump version and add a changelog entry? or also
> > that and do a build?
> >
> > I'm fine with any of those, but I guess builds could interfere with
> > people who are in the middle of rebuilding some stacks.
> >
> > kevin
> >
> >
> >
> > ___
> > 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
> ___
> 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

-- 
Charles R. Anderson, JNCIE-SP   c...@wpi.edu
Network Architect   (508) 831-6110
Network Operations - Morgan Hall(508) 831-
Worcester Polytechnic Institute Fax (508) 831-6669
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Dridi Boukelmoune]

> Yup. I don't fancy reimplementing user/group management in rpm directly,
> I'm thinking more about integrating with existing solutions one way or
> the other. Sysusers is a good candidate since, as you point out, it has
> a declarative syntax already. The biggest problems with any approach
> tend to be with bootstrapping, when installing into an empty chroot
> it'll be a good while until any user management tools are present there,
> yet the early packages need file ownerships just as much as the latter
> ones do. So you'd need to run the tools from outside the chroot and
> that'd basically have to happen before the transaction really starts,
> which has the slight problem that the filesystem isn't populated. Etc.

Hello Panu, Zbyszek,

Thank you for the pointer but you spoiled all the fun I expected for
next Monday's RTFM session ;-(

That being said, I still have more research to do because while this
works fine in Fedora, I'll need to get it working across more systemd
distributions, most of them not of the Fedora lineage... So I guess I
still have a big lump of "fun" ahead of me.

Happy new year and thanks again!


Dridi
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Jakub Jelen]

On Wed, 2018-12-12 at 17:20 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
> 
> == Summary ==
> Remove scriptlets which are not needed anymore (ldconfig,
> gtk-update-icon-cache, etc.).
> 
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Gnatenko]]
> * Email: ignatenkobr...@fedoraproject.org
> 
> == Scope ==
> * Proposal owners: Find appropriate packages and remove obsolete
> scriptlets.
> * Other developers: Package Maintainers are advised to remove
> scriptlets themselves or wait until Proposal Owners will do that.
> * Release engineering: [https://pagure.io/releng/issue/7977 #7977]
> (to
> avoid multiple rebuilds, completing this change before mass rebuild
> is
> advised)

Please, make sure you update and release fedora-review to not require
these scriptlets and warn when they are not needed.

The official review tool still errors if some of the scriptlets that
were removed in the previous batches are needed.

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Panu Matilainen]

On 1/4/19 12:15 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Jan 04, 2019 at 10:56:05AM +0200, Panu Matilainen wrote:

On 1/3/19 5:02 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Jan 03, 2019 at 12:00:13PM +0200, Panu Matilainen wrote:

On 1/3/19 11:47 AM, Dridi Boukelmoune wrote:



On Thu, Jan 3, 2019, 09:59 Panu Matilainen mailto:pmati...@redhat.com> wrote:

  On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
   >> "FV" == Fabio Valentini mailto:decatho...@gmail.com>> writes:
   >
   > FV> - unless those other, main icon theme packages have also added
   > FV> %transfiletrigger* scriptlets, like I've done for elementary and
   > FV> Paper.
   >
   > Perhaps it should be mandatory for icon themes to add the
  necessary file
   > triggers so that no package will ever need to have a scriptlet which
   > calls gtk-update-icon-cache.
   >
   > In general I think that the distro as a whole should pivot towards
   > official, guideline-codified scriptlet avoidance, such that adding
   > appropriate file triggers should be mandatory where it avoids the
  need
   > for packages down the dependency chain to have scriptlets.  I'm sure
   > there are a number of places where this could be done.  Having
  this as a
   > distro-wide goal would make it easier to get changes like the glibc
   > ldconfig file triggers implemented (which took years to get the
  current
   > incomplete implementation pushed).

  +1

  Ultimately the goal should be making the "traditional" scriptlets
  extinct to the point that using them requires an exception.

  I've no illusions here, it's going to be a long long road and require
  further enhancements to rpm (for example dealing with users and groups)
  but that's what the long-term overall goal should be.


I was wondering about the case of users and groups in scriptlets.
Something I would like to investigate next time I dedicate free time to
Fedora is conditional and one-shot services with systemd.

Maybe some of that complexity could move from the package manager to the
service manager. For the use case I have in mind it's definitely the
service that wants the user and group, because none of the installed
files need them. It's only a runtime requirement for the service.


For the case where the packaged files don't need custom user/groups, you can
(and probably should) use systemd facilities already: see sysusers.d(5)

That doesn't help with packaged files though, unless split into a separate
pre-requisite package which is a bit heavy solution for that.


This is a solved problem already.


No it's not.


 From systemd.macros:

# This should be used by package installation scripts which require users or
# groups to be present before the files installed by the package are present on
# disk (for example because some files are owned by those users or groups).
#
# Example:
#   Source1: %{name}-sysusers.conf
#   ...
#   %install
#   install -D %SOURCE1 %{buildroot}%{_sysusersdir}/%{name}.conf
#   %pre
#   %sysusers_create_package %{name} %SOURCE1
#   %files
#   %{_sysusersdir}/%{name}.conf

Also please note that Harald Hoyer and Kay Sievers (in cc) are working on
actually making use of this in Fedora.


Having standard macros for user/group creation is certainly an improvement
over the current situation, but this still requires scriptlets for a task
that should be a declarative item in the spec.


It's "solved" in the sense that a fully working solution exists. It
doesn't require a seperate package. 


Oh okay you were referring to *that* particularly. In that case, yeah.


The biggest advantage is that the data is declarative in the sysusers
file, the information does not have to be duplicated, and the
scriptlet produces the exact same effect as running sysusers after
installation.

Having this implemented directly in rpm would be an improvement, but
wouldn't change a lot for the packager, because we'd still want the
sysusers file to be installed. I'm not even sure if reimplementing
user creation in rpm would be good. A better solution could be something
like %transfiletriggerpre, where a trigger could be installed for some
file patterns and would run before the rest of the package is installed.
I.e. something like those scriptlets do now, but without having to
define the scriptlet in each package.


Yup, only you need the files unpacked in order to do such a thing, and 
at that point it's too late, at least with the way rpm currently works.


Yup. I don't fancy reimplementing user/group management in rpm directly, 
I'm thinking more about integrating with existing solutions one way or 
the other. Sysusers is a good candidate since, as you point out, it has 
a declarative syntax already. The biggest problems with any approach 
tend to be with bootstrapping, when installing into an empty chroot 
it'll be a good while until any user management tools are present 

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jan 04, 2019 at 10:56:05AM +0200, Panu Matilainen wrote:
> On 1/3/19 5:02 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Jan 03, 2019 at 12:00:13PM +0200, Panu Matilainen wrote:
> > > On 1/3/19 11:47 AM, Dridi Boukelmoune wrote:
> > > > 
> > > > 
> > > > On Thu, Jan 3, 2019, 09:59 Panu Matilainen  > > >  wrote:
> > > > 
> > > >  On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
> > > >   >> "FV" == Fabio Valentini  > > >  > writes:
> > > >   >
> > > >   > FV> - unless those other, main icon theme packages have also 
> > > > added
> > > >   > FV> %transfiletrigger* scriptlets, like I've done for 
> > > > elementary and
> > > >   > FV> Paper.
> > > >   >
> > > >   > Perhaps it should be mandatory for icon themes to add the
> > > >  necessary file
> > > >   > triggers so that no package will ever need to have a scriptlet 
> > > > which
> > > >   > calls gtk-update-icon-cache.
> > > >   >
> > > >   > In general I think that the distro as a whole should pivot 
> > > > towards
> > > >   > official, guideline-codified scriptlet avoidance, such that 
> > > > adding
> > > >   > appropriate file triggers should be mandatory where it avoids 
> > > > the
> > > >  need
> > > >   > for packages down the dependency chain to have scriptlets.  I'm 
> > > > sure
> > > >   > there are a number of places where this could be done.  Having
> > > >  this as a
> > > >   > distro-wide goal would make it easier to get changes like the 
> > > > glibc
> > > >   > ldconfig file triggers implemented (which took years to get the
> > > >  current
> > > >   > incomplete implementation pushed).
> > > > 
> > > >  +1
> > > > 
> > > >  Ultimately the goal should be making the "traditional" scriptlets
> > > >  extinct to the point that using them requires an exception.
> > > > 
> > > >  I've no illusions here, it's going to be a long long road and 
> > > > require
> > > >  further enhancements to rpm (for example dealing with users and 
> > > > groups)
> > > >  but that's what the long-term overall goal should be.
> > > > 
> > > > 
> > > > I was wondering about the case of users and groups in scriptlets.
> > > > Something I would like to investigate next time I dedicate free time to
> > > > Fedora is conditional and one-shot services with systemd.
> > > > 
> > > > Maybe some of that complexity could move from the package manager to the
> > > > service manager. For the use case I have in mind it's definitely the
> > > > service that wants the user and group, because none of the installed
> > > > files need them. It's only a runtime requirement for the service.
> > > 
> > > For the case where the packaged files don't need custom user/groups, you 
> > > can
> > > (and probably should) use systemd facilities already: see sysusers.d(5)
> > > 
> > > That doesn't help with packaged files though, unless split into a separate
> > > pre-requisite package which is a bit heavy solution for that.
> > 
> > This is a solved problem already.
> 
> No it's not.
> 
> > From systemd.macros:
> > 
> > # This should be used by package installation scripts which require users or
> > # groups to be present before the files installed by the package are 
> > present on
> > # disk (for example because some files are owned by those users or groups).
> > #
> > # Example:
> > #   Source1: %{name}-sysusers.conf
> > #   ...
> > #   %install
> > #   install -D %SOURCE1 %{buildroot}%{_sysusersdir}/%{name}.conf
> > #   %pre
> > #   %sysusers_create_package %{name} %SOURCE1
> > #   %files
> > #   %{_sysusersdir}/%{name}.conf
> > 
> > Also please note that Harald Hoyer and Kay Sievers (in cc) are working on
> > actually making use of this in Fedora.
> 
> Having standard macros for user/group creation is certainly an improvement
> over the current situation, but this still requires scriptlets for a task
> that should be a declarative item in the spec.

It's "solved" in the sense that a fully working solution exists. It
doesn't require a seperate package. The biggest advantage is that the
data is declarative in the sysusers file, the information does not
have to be duplicated, and the scriptlet produces the exact same effect
as running sysusers after installation.

Having this implemented directly in rpm would be an improvement, but
wouldn't change a lot for the packager, because we'd still want the
sysusers file to be installed. I'm not even sure if reimplementing
user creation in rpm would be good. A better solution could be something
like %transfiletriggerpre, where a trigger could be installed for some
file patterns and would run before the rest of the package is installed.
I.e. something like those scriptlets do now, but without having to
define the scriptlet in each package.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To 

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Panu Matilainen]

On 1/3/19 5:02 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Jan 03, 2019 at 12:00:13PM +0200, Panu Matilainen wrote:

On 1/3/19 11:47 AM, Dridi Boukelmoune wrote:



On Thu, Jan 3, 2019, 09:59 Panu Matilainen mailto:pmati...@redhat.com> wrote:

 On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
  >> "FV" == Fabio Valentini mailto:decatho...@gmail.com>> writes:
  >
  > FV> - unless those other, main icon theme packages have also added
  > FV> %transfiletrigger* scriptlets, like I've done for elementary and
  > FV> Paper.
  >
  > Perhaps it should be mandatory for icon themes to add the
 necessary file
  > triggers so that no package will ever need to have a scriptlet which
  > calls gtk-update-icon-cache.
  >
  > In general I think that the distro as a whole should pivot towards
  > official, guideline-codified scriptlet avoidance, such that adding
  > appropriate file triggers should be mandatory where it avoids the
 need
  > for packages down the dependency chain to have scriptlets.  I'm sure
  > there are a number of places where this could be done.  Having
 this as a
  > distro-wide goal would make it easier to get changes like the glibc
  > ldconfig file triggers implemented (which took years to get the
 current
  > incomplete implementation pushed).

 +1

 Ultimately the goal should be making the "traditional" scriptlets
 extinct to the point that using them requires an exception.

 I've no illusions here, it's going to be a long long road and require
 further enhancements to rpm (for example dealing with users and groups)
 but that's what the long-term overall goal should be.


I was wondering about the case of users and groups in scriptlets.
Something I would like to investigate next time I dedicate free time to
Fedora is conditional and one-shot services with systemd.

Maybe some of that complexity could move from the package manager to the
service manager. For the use case I have in mind it's definitely the
service that wants the user and group, because none of the installed
files need them. It's only a runtime requirement for the service.


For the case where the packaged files don't need custom user/groups, you can
(and probably should) use systemd facilities already: see sysusers.d(5)

That doesn't help with packaged files though, unless split into a separate
pre-requisite package which is a bit heavy solution for that.


This is a solved problem already. 


No it's not.


From systemd.macros:

# This should be used by package installation scripts which require users or
# groups to be present before the files installed by the package are present on
# disk (for example because some files are owned by those users or groups).
#
# Example:
#   Source1: %{name}-sysusers.conf
#   ...
#   %install
#   install -D %SOURCE1 %{buildroot}%{_sysusersdir}/%{name}.conf
#   %pre
#   %sysusers_create_package %{name} %SOURCE1
#   %files
#   %{_sysusersdir}/%{name}.conf

Also please note that Harald Hoyer and Kay Sievers (in cc) are working on
actually making use of this in Fedora.


Having standard macros for user/group creation is certainly an 
improvement over the current situation, but this still requires 
scriptlets for a task that should be a declarative item in the spec.


- Panu -
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 03, 2019 at 12:00:13PM +0200, Panu Matilainen wrote:
> On 1/3/19 11:47 AM, Dridi Boukelmoune wrote:
> > 
> > 
> > On Thu, Jan 3, 2019, 09:59 Panu Matilainen  >  wrote:
> > 
> > On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
> >  >> "FV" == Fabio Valentini  > > writes:
> >  >
> >  > FV> - unless those other, main icon theme packages have also added
> >  > FV> %transfiletrigger* scriptlets, like I've done for elementary and
> >  > FV> Paper.
> >  >
> >  > Perhaps it should be mandatory for icon themes to add the
> > necessary file
> >  > triggers so that no package will ever need to have a scriptlet which
> >  > calls gtk-update-icon-cache.
> >  >
> >  > In general I think that the distro as a whole should pivot towards
> >  > official, guideline-codified scriptlet avoidance, such that adding
> >  > appropriate file triggers should be mandatory where it avoids the
> > need
> >  > for packages down the dependency chain to have scriptlets.  I'm sure
> >  > there are a number of places where this could be done.  Having
> > this as a
> >  > distro-wide goal would make it easier to get changes like the glibc
> >  > ldconfig file triggers implemented (which took years to get the
> > current
> >  > incomplete implementation pushed).
> > 
> > +1
> > 
> > Ultimately the goal should be making the "traditional" scriptlets
> > extinct to the point that using them requires an exception.
> > 
> > I've no illusions here, it's going to be a long long road and require
> > further enhancements to rpm (for example dealing with users and groups)
> > but that's what the long-term overall goal should be.
> > 
> > 
> > I was wondering about the case of users and groups in scriptlets.
> > Something I would like to investigate next time I dedicate free time to
> > Fedora is conditional and one-shot services with systemd.
> > 
> > Maybe some of that complexity could move from the package manager to the
> > service manager. For the use case I have in mind it's definitely the
> > service that wants the user and group, because none of the installed
> > files need them. It's only a runtime requirement for the service.
> 
> For the case where the packaged files don't need custom user/groups, you can
> (and probably should) use systemd facilities already: see sysusers.d(5)
> 
> That doesn't help with packaged files though, unless split into a separate
> pre-requisite package which is a bit heavy solution for that.

This is a solved problem already. From systemd.macros:

# This should be used by package installation scripts which require users or
# groups to be present before the files installed by the package are present on
# disk (for example because some files are owned by those users or groups).
#
# Example:
#   Source1: %{name}-sysusers.conf
#   ...
#   %install
#   install -D %SOURCE1 %{buildroot}%{_sysusersdir}/%{name}.conf
#   %pre
#   %sysusers_create_package %{name} %SOURCE1
#   %files
#   %{_sysusersdir}/%{name}.conf

Also please note that Harald Hoyer and Kay Sievers (in cc) are working on
actually making use of this in Fedora.

Zbyszek
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Panu Matilainen]

On 1/3/19 11:47 AM, Dridi Boukelmoune wrote:



On Thu, Jan 3, 2019, 09:59 Panu Matilainen  wrote:


On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
 >> "FV" == Fabio Valentini mailto:decatho...@gmail.com>> writes:
 >
 > FV> - unless those other, main icon theme packages have also added
 > FV> %transfiletrigger* scriptlets, like I've done for elementary and
 > FV> Paper.
 >
 > Perhaps it should be mandatory for icon themes to add the
necessary file
 > triggers so that no package will ever need to have a scriptlet which
 > calls gtk-update-icon-cache.
 >
 > In general I think that the distro as a whole should pivot towards
 > official, guideline-codified scriptlet avoidance, such that adding
 > appropriate file triggers should be mandatory where it avoids the
need
 > for packages down the dependency chain to have scriptlets.  I'm sure
 > there are a number of places where this could be done.  Having
this as a
 > distro-wide goal would make it easier to get changes like the glibc
 > ldconfig file triggers implemented (which took years to get the
current
 > incomplete implementation pushed).

+1

Ultimately the goal should be making the "traditional" scriptlets
extinct to the point that using them requires an exception.

I've no illusions here, it's going to be a long long road and require
further enhancements to rpm (for example dealing with users and groups)
but that's what the long-term overall goal should be.


I was wondering about the case of users and groups in scriptlets. 
Something I would like to investigate next time I dedicate free time to 
Fedora is conditional and one-shot services with systemd.


Maybe some of that complexity could move from the package manager to the 
service manager. For the use case I have in mind it's definitely the 
service that wants the user and group, because none of the installed 
files need them. It's only a runtime requirement for the service.


For the case where the packaged files don't need custom user/groups, you 
can (and probably should) use systemd facilities already: see sysusers.d(5)


That doesn't help with packaged files though, unless split into a 
separate pre-requisite package which is a bit heavy solution for that.


- Panu -
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Dridi Boukelmoune]

On Thu, Jan 3, 2019, 09:59 Panu Matilainen  On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
> >> "FV" == Fabio Valentini  writes:
> >
> > FV> - unless those other, main icon theme packages have also added
> > FV> %transfiletrigger* scriptlets, like I've done for elementary and
> > FV> Paper.
> >
> > Perhaps it should be mandatory for icon themes to add the necessary file
> > triggers so that no package will ever need to have a scriptlet which
> > calls gtk-update-icon-cache.
> >
> > In general I think that the distro as a whole should pivot towards
> > official, guideline-codified scriptlet avoidance, such that adding
> > appropriate file triggers should be mandatory where it avoids the need
> > for packages down the dependency chain to have scriptlets.  I'm sure
> > there are a number of places where this could be done.  Having this as a
> > distro-wide goal would make it easier to get changes like the glibc
> > ldconfig file triggers implemented (which took years to get the current
> > incomplete implementation pushed).
>
> +1
>
> Ultimately the goal should be making the "traditional" scriptlets
> extinct to the point that using them requires an exception.
>
> I've no illusions here, it's going to be a long long road and require
> further enhancements to rpm (for example dealing with users and groups)
> but that's what the long-term overall goal should be.


I was wondering about the case of users and groups in scriptlets. Something
I would like to investigate next time I dedicate free time to Fedora is
conditional and one-shot services with systemd.

Maybe some of that complexity could move from the package manager to the
service manager. For the use case I have in mind it's definitely the
service that wants the user and group, because none of the installed files
need them. It's only a runtime requirement for the service.

Sent from my phone
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Panu Matilainen]

On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:

"FV" == Fabio Valentini  writes:


FV> - unless those other, main icon theme packages have also added
FV> %transfiletrigger* scriptlets, like I've done for elementary and
FV> Paper.

Perhaps it should be mandatory for icon themes to add the necessary file
triggers so that no package will ever need to have a scriptlet which
calls gtk-update-icon-cache.

In general I think that the distro as a whole should pivot towards
official, guideline-codified scriptlet avoidance, such that adding
appropriate file triggers should be mandatory where it avoids the need
for packages down the dependency chain to have scriptlets.  I'm sure
there are a number of places where this could be done.  Having this as a
distro-wide goal would make it easier to get changes like the glibc
ldconfig file triggers implemented (which took years to get the current
incomplete implementation pushed).


+1

Ultimately the goal should be making the "traditional" scriptlets 
extinct to the point that using them requires an exception.


I've no illusions here, it's going to be a long long road and require 
further enhancements to rpm (for example dealing with users and groups) 
but that's what the long-term overall goal should be.


- Panu -
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Jason L Tibbitts III]

> "FV" == Fabio Valentini  writes:

FV> - unless those other, main icon theme packages have also added
FV> %transfiletrigger* scriptlets, like I've done for elementary and
FV> Paper.

Perhaps it should be mandatory for icon themes to add the necessary file
triggers so that no package will ever need to have a scriptlet which
calls gtk-update-icon-cache.

In general I think that the distro as a whole should pivot towards
official, guideline-codified scriptlet avoidance, such that adding
appropriate file triggers should be mandatory where it avoids the need
for packages down the dependency chain to have scriptlets.  I'm sure
there are a number of places where this could be done.  Having this as a
distro-wide goal would make it easier to get changes like the glibc
ldconfig file triggers implemented (which took years to get the current
incomplete implementation pushed).

 - J<
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Fabio Valentini]

On Fri, Dec 21, 2018, 21:28 Robert-André Mauchin  On mercredi 12 décembre 2018 23:20:54 CET Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
> >
> > == Summary ==
> > Remove scriptlets which are not needed anymore (ldconfig,
> > gtk-update-icon-cache, etc.).
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Gnatenko]]
> > * Email: ignatenkobr...@fedoraproject.org
> >
> > == Scope ==
> > * Proposal owners: Find appropriate packages and remove obsolete
> > scriptlets.
>  * Other developers: Package Maintainers are advised to remove
> > scriptlets themselves or wait until Proposal Owners will do that.
> > * Release engineering: [https://pagure.io/releng/issue/7977 #7977] (to
> > avoid multiple rebuilds, completing this change before mass rebuild is
> > advised)
> > **
> >
> [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|nex
> > t}}|List
>  of deliverables]]: N/A
> > * Policies and guidelines: Guidelines are already updated.
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Installed F30 RPMs on F28/EL6/EL7 might not work although it is not
> > supported.
>
> > == How To Test ==
> > Install new version of package with removed scriptlets and observe
> > that it works.
> >
> > == User Experience ==
> > Installation of packages are faster.
> >
> > == Dependencies ==
> > No specific dependencies.
> >
> > == Contingency Plan ==
> > * Contingency mechanism: Proposal Owners will revert changes which
> > break specific packages when encountered.
> > * Contingency deadline: Final freeze.
> > * Blocks release? No
> >
> > == Documentation ==
> > Everything is already documented in
> > [https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
> > Packaging Guidelines].
> >
> >
>
> Just so we're clear: gtk-update-icon-cache is still needed for directories
> other than hicoler.
>

- unless those other, main icon theme packages have also added
%transfiletrigger* scriptlets, like I've done for elementary and Paper.

But I doubt that there are any packages that add their icons to these icon
themes, anyway.

Fabio


>
> ___
> 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
>
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Robert-André Mauchin]

On mercredi 12 décembre 2018 23:20:54 CET Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
> 
> == Summary ==
> Remove scriptlets which are not needed anymore (ldconfig,
> gtk-update-icon-cache, etc.).
> 
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Gnatenko]]
> * Email: ignatenkobr...@fedoraproject.org
> 
> == Scope ==
> * Proposal owners: Find appropriate packages and remove obsolete
> scriptlets.
 * Other developers: Package Maintainers are advised to remove
> scriptlets themselves or wait until Proposal Owners will do that.
> * Release engineering: [https://pagure.io/releng/issue/7977 #7977] (to
> avoid multiple rebuilds, completing this change before mass rebuild is
> advised)
> **
> [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|nex
> t}}|List
 of deliverables]]: N/A
> * Policies and guidelines: Guidelines are already updated.
> * Trademark approval: N/A (not needed for this Change)
> 
> == Upgrade/compatibility impact ==
> Installed F30 RPMs on F28/EL6/EL7 might not work although it is not
> supported.
 
> == How To Test ==
> Install new version of package with removed scriptlets and observe
> that it works.
> 
> == User Experience ==
> Installation of packages are faster.
> 
> == Dependencies ==
> No specific dependencies.
> 
> == Contingency Plan ==
> * Contingency mechanism: Proposal Owners will revert changes which
> break specific packages when encountered.
> * Contingency deadline: Final freeze.
> * Blocks release? No
> 
> == Documentation ==
> Everything is already documented in
> [https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
> Packaging Guidelines].
> 
> 

Just so we're clear: gtk-update-icon-cache is still needed for directories 
other than hicoler.


___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Igor Gnatenko]

If I manage to get this approved and done before mass rebuild, I'll
just push changes without bumping anything. If it will happen
during/after mass rebuild, I'll also bump.

I'm hoping to complete it before mass rebuild.

On Thu, Dec 20, 2018 at 6:55 PM Kevin Fenzi  wrote:
>
> On 12/20/18 2:35 AM, Dominik 'Rathann' Mierzejewski wrote:
> > On Thursday, 20 December 2018 at 11:29, Richard Hughes wrote:
> >> On Thu, 20 Dec 2018 at 10:16, Hans de Goede  wrote:
> >>> So I say +100 to just pushing the changes directly, as said
> >>> people can always revert them.
> >>
> >> Completely agree. For my packages I'd totally prefer things just
> >> magically be done without any action on my part.
> >
> > Same here and I'm in ACLs for ~100 packages, too. I definitely don't
> > want to deal with a 100 PRs, for something so trivial. I'll revert
> > if necessary, no big deal. Thanks for doing this to Igor, by the way.
>
> Yes, thanks!
>
> However, some clarification: do you intend to just remove the scriptlets
> and thats it? Or, also bump version and add a changelog entry? or also
> that and do a build?
>
> I'm fine with any of those, but I guess builds could interfere with
> people who are in the middle of rebuilding some stacks.
>
> kevin
>
>
>
> ___
> 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
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Jason L Tibbitts III]

> "MH" == Miro Hrončok  writes:

MH> Is there anything we can do to prevent maintains to override the
MH> change with their next "magical sync" from jira/RDO/github/whatever?

MH> I mean we already say they should not do that, but can we somehow
MH> make sure they actually won't?

This question comes up with every mass change that gets auto-reverted.
I took out the needless %defattr calls a while back and several were
added back in, some because of this and some because one maintainer in
particular reverted a bunch of the commits

Certainly there are things we could do, but… we have avoided doing them
in the past.  Possibilities:

* Checks in the git hooks to prevent pushes which introduce certain
  things into specfiles.

* Adding checks as part of the build process (brp scripts, generally) to
  fail builds when things are detected.  Some other distros fail builds
  if rpmlint fails (which obviously would be bad for our current rpmlint
  configuration but could certainly be improved.)

* Some limited checks are available within koji to prevent some classes
  of builds from being tagged.

* More post-build checks (rpmgrill, greenwave).

Most effort has gone into the latter item, which of course gets ignored
just as the existing rules against wiping out changes are ignored.
There has been no will to implement the "stronger" checks.  If those
checks were implemented, the pain would be great due to Fedora's history
of not strongly enforcing this type of "packaging quality", so
everything has to be "opt out" at best and the general case is that
quality checks are "opt in".

 - J<
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Hans de Goede]

Hi,

On 20-12-18 18:45, Kevin Fenzi wrote:

On 12/20/18 2:35 AM, Dominik 'Rathann' Mierzejewski wrote:

On Thursday, 20 December 2018 at 11:29, Richard Hughes wrote:

On Thu, 20 Dec 2018 at 10:16, Hans de Goede  wrote:

So I say +100 to just pushing the changes directly, as said
people can always revert them.


Completely agree. For my packages I'd totally prefer things just
magically be done without any action on my part.


Same here and I'm in ACLs for ~100 packages, too. I definitely don't
want to deal with a 100 PRs, for something so trivial. I'll revert
if necessary, no big deal. Thanks for doing this to Igor, by the way.


Yes, thanks!

However, some clarification: do you intend to just remove the scriptlets
and thats it? Or, also bump version and add a changelog entry? or also
that and do a build?

I'm fine with any of those, but I guess builds could interfere with
people who are in the middle of rebuilding some stacks.


I believe Igor said the idea was to get the changes in place before
the mass rebuild, so we could choose to just make the changes and not
do a build. I do believe we should add a changelog entry (pointing to
the changes page), we can do this kernel.spec style where we add a
changelog entry without a version string after the users name+email,
indicating that no build was done for that change.

Then things won't interfere with any ongoing rebuilding of stacks and
the worst problem is a merge issue with the changelog which is trivial
to fix.

Regards,

Hans
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Kevin Fenzi]

On 12/20/18 2:35 AM, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 20 December 2018 at 11:29, Richard Hughes wrote:
>> On Thu, 20 Dec 2018 at 10:16, Hans de Goede  wrote:
>>> So I say +100 to just pushing the changes directly, as said
>>> people can always revert them.
>>
>> Completely agree. For my packages I'd totally prefer things just
>> magically be done without any action on my part.
> 
> Same here and I'm in ACLs for ~100 packages, too. I definitely don't
> want to deal with a 100 PRs, for something so trivial. I'll revert
> if necessary, no big deal. Thanks for doing this to Igor, by the way.

Yes, thanks!

However, some clarification: do you intend to just remove the scriptlets
and thats it? Or, also bump version and add a changelog entry? or also
that and do a build?

I'm fine with any of those, but I guess builds could interfere with
people who are in the middle of rebuilding some stacks.

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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Adam Williamson]

On Thu, 2018-12-20 at 17:09 +0100, Fabio Valentini wrote:
> On Thu, Dec 20, 2018, 16:57 Adam Williamson wrote:
> 
> > On Thu, 2018-12-20 at 11:50 +0100, Miro Hrončok wrote:
> > > On 12. 12. 18 23:20, Ben Cotton wrote:
> > > > https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
> > > > 
> > > > == Summary ==
> > > > Remove scriptlets which are not needed anymore (ldconfig,
> > > > gtk-update-icon-cache, etc.).
> > > 
> > > Is there anything we can do to prevent maintains to override the change
> > > with their next "magical sync" from jira/RDO/github/whatever?
> > > 
> > > I mean we already say they should not do that, but can we somehow make
> > > sure they actually won't?
> > 
> > AFAIK: No.
> > 
> 
> Well, I think using a git post-receive (?) hook could work - it would then
> reject pushes that reintroduce certain things like Group tags or certain
> scriptlets to .spec files.

Well, let me re-phrase: such a thing is technically possible, but Miro
can't just go ahead and do it. It'd have to be implemented by infra or
whoever's ultimately in charge of the git hooks in package Pagure.

For something which we just absolutely never want to allow any more
this could potentially be simple and work OK, but I think it'd be
rather tricky for anything where we *do* want to allow exceptions.
Which usually turns out to be "nearly everything"...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Igor Gnatenko]

No, it's automation which just pushes new thing for them.

People basically don't care.

On Thu, Dec 20, 2018, 17:55 Zbigniew Jędrzejewski-Szmek  On Thu, Dec 20, 2018 at 11:50:38AM +0100, Miro Hrončok wrote:
> > On 12. 12. 18 23:20, Ben Cotton wrote:
> > >https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
> > >
> > >== Summary ==
> > >Remove scriptlets which are not needed anymore (ldconfig,
> > >gtk-update-icon-cache, etc.).
> >
> >
> > Is there anything we can do to prevent maintains to override the
> > change with their next "magical sync" from jira/RDO/github/whatever?
> >
> > I mean we already say they should not do that, but can we somehow
> > make sure they actually won't?
> >
> >
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity
> >
> > Examples:
> >
> >
> https://src.fedoraproject.org/rpms/subscription-manager/c/90f2a9a9a642ded7488b79a7b689164c2bcdf56e?branch=master
> >
> >
> https://src.fedoraproject.org/rpms/catfish/c/943a8bc22a78d05eee042b964021426c81284d01?branch=master
> >
> >
> https://src.fedoraproject.org/rpms/rhn-client-tools/c/eb797600f7902ad0507452eca97caf7f76d0341d?branch=master
> >
> >
> https://src.fedoraproject.org/rpms/python-importanize/c/2228c1194a8c29c9baafdf9982b7b3d186b42c94?branch=master
> >
> >
> https://src.fedoraproject.org/rpms/glusterfs/c/97c4e2fb0440d34dde2bffcf6338d8b04cd023fb?branch=master
>
> That's just nasty. Don't people do at least do a 'git show' before pushing?
>
> Zbyszek
> ___
> 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
>
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 20, 2018 at 11:50:38AM +0100, Miro Hrončok wrote:
> On 12. 12. 18 23:20, Ben Cotton wrote:
> >https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
> >
> >== Summary ==
> >Remove scriptlets which are not needed anymore (ldconfig,
> >gtk-update-icon-cache, etc.).
> 
> 
> Is there anything we can do to prevent maintains to override the
> change with their next "magical sync" from jira/RDO/github/whatever?
> 
> I mean we already say they should not do that, but can we somehow
> make sure they actually won't?
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity
> 
> Examples:
> 
> https://src.fedoraproject.org/rpms/subscription-manager/c/90f2a9a9a642ded7488b79a7b689164c2bcdf56e?branch=master
> 
> https://src.fedoraproject.org/rpms/catfish/c/943a8bc22a78d05eee042b964021426c81284d01?branch=master
> 
> https://src.fedoraproject.org/rpms/rhn-client-tools/c/eb797600f7902ad0507452eca97caf7f76d0341d?branch=master
> 
> https://src.fedoraproject.org/rpms/python-importanize/c/2228c1194a8c29c9baafdf9982b7b3d186b42c94?branch=master
> 
> https://src.fedoraproject.org/rpms/glusterfs/c/97c4e2fb0440d34dde2bffcf6338d8b04cd023fb?branch=master

That's just nasty. Don't people do at least do a 'git show' before pushing?

Zbyszek
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Fabio Valentini]

On Thu, Dec 20, 2018, 16:57 Adam Williamson On Thu, 2018-12-20 at 11:50 +0100, Miro Hrončok wrote:
> > On 12. 12. 18 23:20, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
> > >
> > > == Summary ==
> > > Remove scriptlets which are not needed anymore (ldconfig,
> > > gtk-update-icon-cache, etc.).
> >
> > Is there anything we can do to prevent maintains to override the change
> > with their next "magical sync" from jira/RDO/github/whatever?
> >
> > I mean we already say they should not do that, but can we somehow make
> > sure they actually won't?
>
> AFAIK: No.
>

Well, I think using a git post-receive (?) hook could work - it would then
reject pushes that reintroduce certain things like Group tags or certain
scriptlets to .spec files.

-- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> 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
> 
>
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Adam Williamson]

On Thu, 2018-12-20 at 11:50 +0100, Miro Hrončok wrote:
> On 12. 12. 18 23:20, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
> > 
> > == Summary ==
> > Remove scriptlets which are not needed anymore (ldconfig,
> > gtk-update-icon-cache, etc.).
> 
> Is there anything we can do to prevent maintains to override the change 
> with their next "magical sync" from jira/RDO/github/whatever?
> 
> I mean we already say they should not do that, but can we somehow make 
> sure they actually won't?

AFAIK: No.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Miro Hrončok]

On 12. 12. 18 23:20, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets

== Summary ==
Remove scriptlets which are not needed anymore (ldconfig,
gtk-update-icon-cache, etc.).



Is there anything we can do to prevent maintains to override the change 
with their next "magical sync" from jira/RDO/github/whatever?


I mean we already say they should not do that, but can we somehow make 
sure they actually won't?


https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity

Examples:

https://src.fedoraproject.org/rpms/subscription-manager/c/90f2a9a9a642ded7488b79a7b689164c2bcdf56e?branch=master

https://src.fedoraproject.org/rpms/catfish/c/943a8bc22a78d05eee042b964021426c81284d01?branch=master

https://src.fedoraproject.org/rpms/rhn-client-tools/c/eb797600f7902ad0507452eca97caf7f76d0341d?branch=master

https://src.fedoraproject.org/rpms/python-importanize/c/2228c1194a8c29c9baafdf9982b7b3d186b42c94?branch=master

https://src.fedoraproject.org/rpms/glusterfs/c/97c4e2fb0440d34dde2bffcf6338d8b04cd023fb?branch=master
--
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://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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Miro Hrončok]

On 19. 12. 18 11:22, Igor Gnatenko wrote:

On Wed, Dec 19, 2018 at 2:20 AM Jason L Tibbitts III  wrote:



"ZJ" == Zbigniew Jędrzejewski-Szmek  writes:


ZJ> I think it's pretty clear: all the standard invocations of
ZJ> scriptlets that have by replaced by transfiletriggers will be
ZJ> removed, along with the whole %post/%postun sections if its the only
ZJ> thing in them.

I do think it would be better to list exactly what is expected to be
changed (and which packages actually need which changes).


Done.

* ldconfig scriptlets will be removed (or by maintainer request will
be replaced by %ldconfig_scriptlets macro which exists on Fedora and
EPEL)
* gtk-update-icon-cache, glib-compile-schemas,
gdk-pixbuf-query-loaders, gtk-query-immodules-3.0, gio-querymodules
and install-info will be removed (or by maintainer request will be
guarded with %if's)



Or, announce the date of the change and just check in your automation:

 * is there a ldcofig macro? don't change
 * is it guwarded by if? don't change

And remove anything else.

Maintainers who want "single spec" can easily just add the guards if 
they want to protect themselves form changes or add the scriptlet 
guarded after.



--
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://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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Dominik 'Rathann' Mierzejewski]

On Thursday, 20 December 2018 at 11:29, Richard Hughes wrote:
> On Thu, 20 Dec 2018 at 10:16, Hans de Goede  wrote:
> > So I say +100 to just pushing the changes directly, as said
> > people can always revert them.
> 
> Completely agree. For my packages I'd totally prefer things just
> magically be done without any action on my part.

Same here and I'm in ACLs for ~100 packages, too. I definitely don't
want to deal with a 100 PRs, for something so trivial. I'll revert
if necessary, no big deal. Thanks for doing this to Igor, by the way.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Richard Hughes]

On Thu, 20 Dec 2018 at 10:16, Hans de Goede  wrote:
> So I say +100 to just pushing the changes directly, as said
> people can always revert them.

Completely agree. For my packages I'd totally prefer things just
magically be done without any action on my part.

Richard.
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Neal Gompa]

On Thu, Dec 20, 2018 at 5:17 AM Hans de Goede  wrote:
>
> Hi,
>
> On 20-12-18 10:54, Raphael Groner wrote:
> >> So what process should I use? Pull Requests or just removing obsolete 
> >> stuff?
> >> I'm ready to do either way. Should I leave this to FESCo?
> >
> > My vote would go for Pull Requests to give the packagers a (limited) chance 
> > to look into the proposal individually. Maybe after some elapsed time have 
> > waited, you or someone else could just merge with the force of 
> > provenpackager.
>
> Ugh no I maintain somewhere between a 100 and 200 packages in Fedora,
> just push the changes directly please. 100-200 pull-reqs is going to
> be a big pain.
>
> Even just deleting all the notifications from them, without maybe
> also accidentally deleting a non automated pullreq is goind to be
> a big pain.
>
> So I say +100 to just pushing the changes directly, as said
> people can always revert them.
>
> Maybe add a note in the changes page about this and a link
> to the changes page in the spec file changelog, something like:
> -For more info see: http://
>

+100

Please, just push the changes. We'll all get notified anyway via
fedmsg or other means that a change has been pushed. The PR-based
method was too obnoxious when it was done for the Python dependency
change.



-- 
真実はいつも一つ！/ 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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Hans de Goede]

Hi,

On 20-12-18 10:54, Raphael Groner wrote:

So what process should I use? Pull Requests or just removing obsolete stuff?
I'm ready to do either way. Should I leave this to FESCo?


My vote would go for Pull Requests to give the packagers a (limited) chance to 
look into the proposal individually. Maybe after some elapsed time have waited, 
you or someone else could just merge with the force of provenpackager.


Ugh no I maintain somewhere between a 100 and 200 packages in Fedora,
just push the changes directly please. 100-200 pull-reqs is going to
be a big pain.

Even just deleting all the notifications from them, without maybe
also accidentally deleting a non automated pullreq is goind to be
a big pain.

So I say +100 to just pushing the changes directly, as said
people can always revert them.

Maybe add a note in the changes page about this and a link
to the changes page in the spec file changelog, something like:
-For more info see: http://

Regards,

Hans
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Raphael Groner]

> So what process should I use? Pull Requests or just removing obsolete stuff?
> I'm ready to do either way. Should I leave this to FESCo?

My vote would go for Pull Requests to give the packagers a (limited) chance to 
look into the proposal individually. Maybe after some elapsed time have waited, 
you or someone else could just merge with the force of provenpackager.
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Igor Gnatenko]

Ok, so I put my preferred way of doing it:
https://fedoraproject.org/w/index.php?title=Changes%2FRemoveObsoleteScriptlets=revision=530714=530690

Once there will be FESCo ticket (which actually should have been sent
yesterday), I'll definitely would like to hear FESCo opinion and ready
to change proposal.

Thanks for the feedback!

On Thu, Dec 20, 2018 at 8:35 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Dec 20, 2018 at 07:38:29AM +0100, Igor Gnatenko wrote:
> > So what process should I use? Pull Requests or just removing obsolete
> > stuff? I'm ready to do either way. Should I leave this to FESCo?
>
> The choice of implementation details is yours. You can always ask
> FESCo for opinion, but I don't think you'll get one that is much more
> definitive than the discussion here on the list.
>
> Zbyszek
>
> > On Wed, Dec 19, 2018 at 8:00 PM Jason L Tibbitts III  
> > wrote:
> > >
> > > > "KL" == Kalev Lember  writes:
> > >
> > > KL> I agree with Zbyszek, I think it would be best to push the changes
> > > KL> directly to git.
> > >
> > > But then we're back to the same problem: Do you remove the ldconfig
> > > calls entirely or do you add the macros?  Prepare for flames if you get
> > > it wrong, even though it's nontrivial to get it right and reverting is
> > > far quicker than flaming.  Then again, getting people more used to the
> > > idea that automated process are going to be making changes to packages
> > > is a good thing.
> > >
> > > All of this reminds me that it's well past time to move forward with the
> > > mass Group: removal.  At least that one is a trivial change.
> ___
> 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
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 20, 2018 at 07:38:29AM +0100, Igor Gnatenko wrote:
> So what process should I use? Pull Requests or just removing obsolete
> stuff? I'm ready to do either way. Should I leave this to FESCo?

The choice of implementation details is yours. You can always ask
FESCo for opinion, but I don't think you'll get one that is much more
definitive than the discussion here on the list.

Zbyszek

> On Wed, Dec 19, 2018 at 8:00 PM Jason L Tibbitts III  
> wrote:
> >
> > > "KL" == Kalev Lember  writes:
> >
> > KL> I agree with Zbyszek, I think it would be best to push the changes
> > KL> directly to git.
> >
> > But then we're back to the same problem: Do you remove the ldconfig
> > calls entirely or do you add the macros?  Prepare for flames if you get
> > it wrong, even though it's nontrivial to get it right and reverting is
> > far quicker than flaming.  Then again, getting people more used to the
> > idea that automated process are going to be making changes to packages
> > is a good thing.
> >
> > All of this reminds me that it's well past time to move forward with the
> > mass Group: removal.  At least that one is a trivial change.
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Igor Gnatenko]

So what process should I use? Pull Requests or just removing obsolete
stuff? I'm ready to do either way. Should I leave this to FESCo?

On Wed, Dec 19, 2018 at 8:00 PM Jason L Tibbitts III  wrote:
>
> > "KL" == Kalev Lember  writes:
>
> KL> I agree with Zbyszek, I think it would be best to push the changes
> KL> directly to git.
>
> But then we're back to the same problem: Do you remove the ldconfig
> calls entirely or do you add the macros?  Prepare for flames if you get
> it wrong, even though it's nontrivial to get it right and reverting is
> far quicker than flaming.  Then again, getting people more used to the
> idea that automated process are going to be making changes to packages
> is a good thing.
>
> All of this reminds me that it's well past time to move forward with the
> mass Group: removal.  At least that one is a trivial change.
>
>  - J<
> ___
> 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
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 19, 2018 at 12:49:51PM -0600, Jason L Tibbitts III wrote:
> > "KL" == Kalev Lember  writes:
> 
> KL> I agree with Zbyszek, I think it would be best to push the changes
> KL> directly to git.
> 
> But then we're back to the same problem: Do you remove the ldconfig
> calls entirely or do you add the macros?  Prepare for flames if you get
> it wrong, even though it's nontrivial to get it right and reverting is
> far quicker than flaming.
For me that is the crucial point: why do we make such a big thing out of
those issues, when 'git reset -p HEAD~' takes less time then writing
a mail.

>  Then again, getting people more used to the
> idea that automated process are going to be making changes to packages
> is a good thing.
Exactly.

> All of this reminds me that it's well past time to move forward with the
> mass Group: removal.  At least that one is a trivial change.

Zbyszek
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Jason L Tibbitts III]

> "KL" == Kalev Lember  writes:

KL> I agree with Zbyszek, I think it would be best to push the changes
KL> directly to git.

But then we're back to the same problem: Do you remove the ldconfig
calls entirely or do you add the macros?  Prepare for flames if you get
it wrong, even though it's nontrivial to get it right and reverting is
far quicker than flaming.  Then again, getting people more used to the
idea that automated process are going to be making changes to packages
is a good thing.

All of this reminds me that it's well past time to move forward with the
mass Group: removal.  At least that one is a trivial change.

 - J<
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Kalev Lember]

On Wed, Dec 19, 2018, 15:09 Zbigniew Jędrzejewski-Szmek  On Wed, Dec 19, 2018 at 11:22:21AM +0100, Igor Gnatenko wrote:
> > I've updated change which is explicitly mentions that I'm going to
> > send Pull Requests to packages, so it should not make anyone unhappy.
>
> Are you sure this is a viable approach?
>
> $ rpm -qa --scripts|grep ldconfig|wc -l
> 1130
>
> (and I have only 5k packages installed, 20% of the whole distro?).
> Counting one PR for every two ldconfigs, you'd have to open maybe
> 500-2000 PRs. Not only is it a waste of _your_ time, but of the other
> 500-2000 people to answer this.
>

I agree with Zbyszek, I think it would be best to push the changes directly
to git.

Kalev
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 19, 2018 at 11:22:21AM +0100, Igor Gnatenko wrote:
> On Wed, Dec 19, 2018 at 2:20 AM Jason L Tibbitts III  
> wrote:
> >
> > > "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
> >
> > ZJ> I think it's pretty clear: all the standard invocations of
> > ZJ> scriptlets that have by replaced by transfiletriggers will be
> > ZJ> removed, along with the whole %post/%postun sections if its the only
> > ZJ> thing in them.
> >
> > I do think it would be better to list exactly what is expected to be
> > changed (and which packages actually need which changes).
> 
> Done.
> 
> * ldconfig scriptlets will be removed (or by maintainer request will
> be replaced by %ldconfig_scriptlets macro which exists on Fedora and
> EPEL)
> * gtk-update-icon-cache, glib-compile-schemas,
> gdk-pixbuf-query-loaders, gtk-query-immodules-3.0, gio-querymodules
> and install-info will be removed (or by maintainer request will be
> guarded with %if's)
> 
> 
> > ZJ> I think that the way this should be handled is that if maintainers
> > ZJ> of a package want to use a single branch for F30+ and
> > ZJ> EPEL/RHEL/whatever, it is on them to arrange the spec file with the
> > ZJ> appropriate conditionals.
> >
> > Well, that's what makes it tough.  You can remove the scriptlets, or you
> > can replace them with the various sets of macros which do nothing on
> > Fedora and do something on EPEL (to the extent that is even possible).
> > The macros needed are often context-dependent.  Certainly just removing
> > things is simplest but will cause the most upset.
> >
> > It's not trivial to know if a maintainer insists on the single spec
> > approach, so it can be rather difficult to do this in an automated
> > fashion.  Of course it would be easy if everyone just fixed the packages
> > they maintain so that there's no need for automated fixup.  I'd hope
> > that some of that might happen if the lists of packages which need
> > changes are provided.  I did some of that a couple of releases ago and I
> > could try to do it again if someone could lengthen the day by a few
> > hours.
> 
> I've updated change which is explicitly mentions that I'm going to
> send Pull Requests to packages, so it should not make anyone unhappy.

Are you sure this is a viable approach?

$ rpm -qa --scripts|grep ldconfig|wc -l
1130

(and I have only 5k packages installed, 20% of the whole distro?).
Counting one PR for every two ldconfigs, you'd have to open maybe
500-2000 PRs. Not only is it a waste of _your_ time, but of the other
500-2000 people to answer this.

Zbyszek
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Igor Gnatenko]

On Wed, Dec 19, 2018 at 2:20 AM Jason L Tibbitts III  wrote:
>
> > "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
>
> ZJ> I think it's pretty clear: all the standard invocations of
> ZJ> scriptlets that have by replaced by transfiletriggers will be
> ZJ> removed, along with the whole %post/%postun sections if its the only
> ZJ> thing in them.
>
> I do think it would be better to list exactly what is expected to be
> changed (and which packages actually need which changes).

Done.

* ldconfig scriptlets will be removed (or by maintainer request will
be replaced by %ldconfig_scriptlets macro which exists on Fedora and
EPEL)
* gtk-update-icon-cache, glib-compile-schemas,
gdk-pixbuf-query-loaders, gtk-query-immodules-3.0, gio-querymodules
and install-info will be removed (or by maintainer request will be
guarded with %if's)


> ZJ> I think that the way this should be handled is that if maintainers
> ZJ> of a package want to use a single branch for F30+ and
> ZJ> EPEL/RHEL/whatever, it is on them to arrange the spec file with the
> ZJ> appropriate conditionals.
>
> Well, that's what makes it tough.  You can remove the scriptlets, or you
> can replace them with the various sets of macros which do nothing on
> Fedora and do something on EPEL (to the extent that is even possible).
> The macros needed are often context-dependent.  Certainly just removing
> things is simplest but will cause the most upset.
>
> It's not trivial to know if a maintainer insists on the single spec
> approach, so it can be rather difficult to do this in an automated
> fashion.  Of course it would be easy if everyone just fixed the packages
> they maintain so that there's no need for automated fixup.  I'd hope
> that some of that might happen if the lists of packages which need
> changes are provided.  I did some of that a couple of releases ago and I
> could try to do it again if someone could lengthen the day by a few
> hours.

I've updated change which is explicitly mentions that I'm going to
send Pull Requests to packages, so it should not make anyone unhappy.

>  - J<
> ___
> 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
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Jason L Tibbitts III]

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> I think it's pretty clear: all the standard invocations of
ZJ> scriptlets that have by replaced by transfiletriggers will be
ZJ> removed, along with the whole %post/%postun sections if its the only
ZJ> thing in them.

I do think it would be better to list exactly what is expected to be
changed (and which packages actually need which changes).

ZJ> I think that the way this should be handled is that if maintainers
ZJ> of a package want to use a single branch for F30+ and
ZJ> EPEL/RHEL/whatever, it is on them to arrange the spec file with the
ZJ> appropriate conditionals.

Well, that's what makes it tough.  You can remove the scriptlets, or you
can replace them with the various sets of macros which do nothing on
Fedora and do something on EPEL (to the extent that is even possible).
The macros needed are often context-dependent.  Certainly just removing
things is simplest but will cause the most upset.

It's not trivial to know if a maintainer insists on the single spec
approach, so it can be rather difficult to do this in an automated
fashion.  Of course it would be easy if everyone just fixed the packages
they maintain so that there's no need for automated fixup.  I'd hope
that some of that might happen if the lists of packages which need
changes are provided.  I did some of that a couple of releases ago and I
could try to do it again if someone could lengthen the day by a few
hours.

 - J<
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 17, 2018 at 11:31:46AM -0800, Japheth Cleaver wrote:
> On 12/12/2018 2:20 PM, Ben Cotton wrote:
> >https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
> >
> >== Summary ==
> >Remove scriptlets which are not needed anymore (ldconfig,
> >gtk-update-icon-cache, etc.).
> >
> >*snip*
> >
> >== Upgrade/compatibility impact ==
> >Installed F30 RPMs on F28/EL6/EL7 might not work although it is not 
> >supported.
> >
> There's not much description in the link about what's actually going
> to happen here and what's being removed from .specs.

I think it's pretty clear: all the standard invocations of scriptlets
that have by replaced by transfiletriggers will be removed, along with
the whole %post/%postun sections if its the only thing in them.

> Is there going to to be any attempt at coordination of this with
> EPEL? Or, if these are already macros in the .specs, has there been
> thought given to simply changing some of these to no-op macros in
> Fedora instead of removing them entirely?

I think that the way this should be handled is that if maintainers of
a package want to use a single branch for F30+ and EPEL/RHEL/whatever,
it is on them to arrange the spec file with the appropriate conditionals.

Then, scripts implementing this should only touch those packages which
have the scriptlet in the *binary* package. I.e. filter the list of
packages to update by actual 'rpm -qp --scripts' output.

There are multiple mechanism to achieve this:
- general %if checks
- %ldconfig_scriptlets and similar that evaluate to %nil
  ({?ldconfig}, %ldconfig_post, %ldconfig_postun)

Such division of labour makes it possible for the Change owner to
implement this in reasonable time, but still allows individual maintainers
to implement their custom solutions.

Zbyszek
___
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

Re: Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets

[Japheth Cleaver]

On 12/12/2018 2:20 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets

== Summary ==
Remove scriptlets which are not needed anymore (ldconfig,
gtk-update-icon-cache, etc.).

*snip*

== Upgrade/compatibility impact ==
Installed F30 RPMs on F28/EL6/EL7 might not work although it is not supported.

There's not much description in the link about what's actually going to 
happen here and what's being removed from .specs.


Is there going to to be any attempt at coordination of this with EPEL? 
Or, if these are already macros in the .specs, has there been thought 
given to simply changing some of these to no-op macros in Fedora instead 
of removing them entirely?


-jc
___
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