[Rpm-ecosystem] IRC channels move to Libera.chat
The recent developments in what used to be the freenode IRC network force us to look for a new home for our IRC channels. As a result we - as so many other projects - are moving to the Libera.chat network. Discussion about the RPM tool and project itself can continue in the #rpm channel there. Topics about the wider ecosystem including updaters, repository tools, etc are welcome in #rpm-ecosystem For some time we will maintain an #rpm.org channel pointing people to the #rpm main channel. See https://libera.chat/guides and how to join and register a nick name. The RPM team -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Dynamic subpackages
Ok, to translate this to a more generalized feature: Something needs to create those package declarations during build. For rust this may be done after %prep but the right time is probably after %install (or after %check). This way everything there is to be known about the build is on disk already and the script can look at whatever it wants. They then would need to be parsed into package objects. One way to achieve this could be just re-parsing the whole spec file and have some part only expanded then. That way macros defined in there could be used in other parts. This is probably much more convenient than a solution that just parses the output on top of what was read earlier which would take this part out of the order of the rest of the spec file. This raises a few questions about consistency when the result of the first pass and the second pass differ. But that might not be a problem. The build scripts will be used anymore anyway. Package declarations are not really used during building. So using the new version should not break anything. The concrete file lists would ofc be only created afterwards - same for the automatic dependencies and the actual (binary) packages. According the Neal openSuSE already does something very similar by "doing on-demand rewriting of the spec file through macros and forcing rpm to reprocess the spec file (%python_subpackages, %rubygem_subpackages, etc.)" I have not yet looked into this. But if someone has some pointers, feel free to post them here. Florian -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] RPM creation - show a message in case of installation fail
On 5/14/19 5:18 PM, Stefano Simonelli wrote: > HI everyone, > > during the creation of a RPM in the .spec file - > > is there a way to print a message if the RPM installation fails for some > reasons, for example not able to solve the dependencies ? Well, rpm (and all other tools dealing with rpm packages) already print a message if dependencies are not met. Packages themselves otoh can not issue a message on their own. This is on purpose. Installing, updating and removing packages is expected to be able to run unattended. Scriptlets are therefore run with standardout disconnected from the terminal. In case of unresolved dependencies there are not scriptlets executed anyway. The only way to convey the issue to the user is choosing descriptive names for the dependencies. But the better way around this whole issue is to provide the packages as part of a repository that contains everything needed that's not part of the distribution(s) the package is supposed to run on. Florian -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Is there anything I can do to help zchunk reviews along?
On 06/29/2018 01:09 PM, Jonathan Dieter wrote: > Ok, I've put together an initial proposal at https://fedoraproject.org/ > wiki/Changes/Zchunk_Metadata. In case you need another argument why this is important: Fedora is still growing at a linear or may be slightly above linear rate. So the amount of meta data is going to continue to increase. I updated my "Growth of Fedora" document I created in 2011 after the release of Fedora 14. IIRC my estimation back then was that we need to be able to handle the meta data of around 50,000 packages to be save for the next 5 years. This lines up pretty nicely with the plot which you can find on sheet 2 of the document. Florian -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill Fedora-Statistics.ods Description: application/vnd.oasis.opendocument.spreadsheet ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
[Rpm-ecosystem] New RPM-Extras repository
Hi! For quite a while it has become apparent that there are many scripts, macro files and other rpm related pieces that all the different distributions maintain on their own. We have been trying to get some of this merged upstream but there is only so much that can be done there. Some things are just not suited for the rpm repository. Nevertheless having things scattered is not a good solution either. So we just created a new repository: rpm-extras [1] There are two major uses we see for this repo: 1) Distributions can put in their scripts and macros and collaborate to merge them into more stable and general versions. 2) Dependency generators for more exotic file types. >From the repo README.md: We encourage distributions to add their own scripts here. It is perfectly fine to have multiple versions of same or similar scripts in the repositories. Please create a sub directory with the name of the distribution in brpscripts/ or macros.d/. The idea is to collect the different implementations and merge them to more general, refined and stable versions. This repository is meant to help with this process. But we are aware that the needs of the distributions differ. It is perfectly fine to end up with multiple variants of the same scripts without an perspective to get them merged. We still hope that for most cases we can settle for one, two or may be three different variants at most. Although this repository will not follow the release cycle of rpm the content is supposed to be compatible with the current stable release of rpm. We do not collect all versions of the scripts used is some release of each distro. As a general rule of thumb: one version per distribution max. Separate version may be acceptable for down stream (enterprise/long term support) distributions if they differ in the policy they implement. The idea is that access to this repository is less strict than for the RPM repository. Distributions are encourage to take responsibility for their sub directories throughout the repository. For files shared between distributions it is expected to discuss changes on the rpm-ecosystem mailing list and to create pull requests on Git Hub or send patches for review. Florian [1] https://github.com/rpm-software-management/rpm-extras -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
[Rpm-ecosystem] RFC #417 %optional file attribute
Hi! We are currently pondering about #417 [1]. For adding a %optional file attribute that would allow adding file to to %files sections that may not be built under some circumstances (e.g. some architectures). It is already perfectly legal to have files not listed explicitly if they are within a directory that is included in the %file section. But some packages (examples wanted) may have trouble using this due to the way the package files are laid out. Otoh %optional would be another spec language key word that packagers have to deal with and we as RPM upstream developers have a hard time judging whether the benefit of the attribute really out weights the cost of bloating the spec language. Any input - especially with real world packages that would benefit such an addition - is welcome. Florian [1] https://github.com/rpm-software-management/rpm/pull/417 -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Rich deps syntax finalization
On 10/18/2016 05:23 PM, Pat Riehecky wrote: > Can a link to http://rpm.org/wiki/PackagerDocs/BooleanDependencies be > added to > http://www.rpm.org/wiki/PackagerDocs/Dependencies ? Good point. Done! Florian -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Sync of rpm macros between Fedora/openSUSE
On 04/11/2016 08:30 PM, Zbigniew Jędrzejewski-Szmek wrote: >> I would shoot for idea where the bla.macros would just sit in git and >> the packages would specify as sources the macros ie.: >> Source99: https://github.com/rpm/rpm-macros/archive/python.macros Yes. This is about what I had in mind when suggesting a shared repo. There is no point in making this a real "package" with release cycles and everything that comes with it. Think more of it like an wiki where people can share patches and ideas and pull out the exact version of the file they need for one particular packager in their distro - may be even applying some more patches on top. > This moves those macros under the maintenance of the rpm team. > I guess this could work for a few projects, let's say perl and python, > but I don't see how this can scale (to perl, python, java, js, lisp, mono, > swift, node, ocaml, octave, php, R, ruby, tcl, etc, etc, etc). > RPM should instead provide a featureful base upon which individual > projects can build. I fully agree with you here. The idea is not to get "those macros under the maintenance of the rpm team". We - as rpm upstream - can't and don't want to take over the work that the distros need to do. This is about offering a shared and neutral place where people from different distros can meet, easily have a look what everyone else is doing and talk about where they can share the same macros - and where not. So my idea is to have a repository where like two, three dozen people may have either commit access or have people closely at hand that can merge in their changes. So the content is actually maintained by people from the different distros that do have the domain knowledge of all those languages or package types. I think this is acceptable security wise as people are supposed to have an eye on the files they care about and not blindly pull them out of the repo. Florian -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
[Rpm-ecosystem] RFC: Better handling of per distro RPM macros
Hi! Looking at the pull requests #37 and #38 [1] for a while I came to the conclusion that RPM macros are quite a mess. But I could not really come up with a way to get things cleaned up without breaking existing packages. In general it is clear that distros and possibly even single packages within distros need control over some RPM macros. The speed of rpm upstream is just not suited to make quick changes and trying out new things. Also changes to packaging need to be in sync with the distros live cycle and updating to a new rpm release should not change how packages get build. That's the reason Fedora (as an example) has most of its macros in a separate package: redhat-rpm-config. I wonder if it made sense to have an shared git repository where distros (or development packages within those distros) can share their macro files. Probably with some shared files on the top level and with per vendor/distro/may be even distro release sub directories. For one the would make it much easier to see what other distributions do or how they solve specific problems. Also it would allow global changes while keeping the per vendor versions unaffected by pushing the old behavior down into the vendor files. Is this something people are interested in? What layout/features/policies should such a repository have? Does it need special things like sections for languages like Perl, Python, ... or features like language sub packages, debuginfo packages, ... ? Florian [1] https://github.com/rpm-software-management/rpm/pull/37 https://github.com/rpm-software-management/rpm/pull/38 -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Rich deps syntax finalization
On 09/01/2015 02:20 AM, Neal Gompa wrote: > On Mon, Aug 31, 2015 at 10:14 AM, Florian Festi <ffe...@redhat.com > <mailto:ffe...@redhat.com>>wrote: > > My thought after the discussion so far: > > May be no one really cares about the syntax. > Still a lot of educating to do before rich deps go into production. > > > On 08/25/2015 02:11 PM, Florian Festi wrote: > > > IF Operator > > Guess we stay with (. IF . ELSE .) - even some people are more familiar > with (. ? . : .). > > > We discussed whether the operators should be upper or lower case or case > > insensitive. So far we think *upper case* is better as is stands out > > between the typically lower case package names. But we are interested on > > second opinions on this, too. > > I am now tending to actually *use lower case*. This is what most > programming languages do. May be familiarity beats emphasizing the > operators with CAPS. > > So (. if . else .) > > > This makes sense. After all, the parenthesis already denotes that the > if/else clauses are meaningful. > > > > > AND and OR > > == > > I think we go for "and" and "or" for consistency. In the end it is > really close with | and & to stay with dpkg. What pushed it over to and, > or was having a different but consistent style for the rich deps - in > opposite to macros and version comparisons. > > > I'm okay with this. Will "or" have an ordering component (and thus, > short-circuit logic capability from left to right)? Or will it remain > order-less and fully evaluated each time? For dependency checking (which is what rpm does) there is no difference between short circuit and full evaluation. Libsolv - the currently only dependency solver with rich deps support - does not order the "or" terms but instead tries to pick the "best" of all packages - no matter of the order within the dependency. While we have discussed about adding this there are several reasons not to: * We have Suggests and Enhances which can be used to state package preferences * The semantic is not that clear if you have nested expressions * Especially in combination with Suggests and Enhances * The implementation may be tricky as the rules get normalized to conjunctive normal form before solving > > NOT not? > > > > NOT is confusing people and they have problems coming up with real use > cases. So we will go without for now and reconsider when real need > arises. > > > What would you consider real use cases? Well, an existing packages with needs to solve an issue but has trouble doing so without the NOT operator. I would even accept if writing the dependency without NOT is more cumbersome. But so far I have not seen a single existing package that would actually benefit. > Speak now or forever hold your peace. > > > I think this counts as speaking. ;) > > > > > Florian > > -- > > Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael > O'Neill, Charles Peters > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > > > ___ > Rpm-ecosystem mailing list > Rpm-ecosystem@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem > -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Rich deps syntax finalization
My thought after the discussion so far: May be no one really cares about the syntax. Still a lot of educating to do before rich deps go into production. On 08/25/2015 02:11 PM, Florian Festi wrote: > IF Operator Guess we stay with (. IF . ELSE .) - even some people are more familiar with (. ? . : .). > We discussed whether the operators should be upper or lower case or case > insensitive. So far we think *upper case* is better as is stands out > between the typically lower case package names. But we are interested on > second opinions on this, too. I am now tending to actually *use lower case*. This is what most programming languages do. May be familiarity beats emphasizing the operators with CAPS. So (. if . else .) > AND and OR > == I think we go for "and" and "or" for consistency. In the end it is really close with | and & to stay with dpkg. What pushed it over to and, or was having a different but consistent style for the rich deps - in opposite to macros and version comparisons. > NOT not? > NOT is confusing people and they have problems coming up with real use cases. So we will go without for now and reconsider when real need arises. Speak now or forever hold your peace. Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Rich deps syntax finalization
On 08/26/2015 02:58 PM, Vít Ondruch wrote: Dne 26.8.2015 v 14:00 Florian Festi napsal(a): On 08/26/2015 10:47 AM, Florian Festi wrote: Right now libsolv does not distinguish between different orders of the operands. But we have already discussed making the OR operator preferring the left most operand. This is something RPM does not really care about but of cause has implications for packaging if implemented in libsolv. May be I should append to this slightly: AFAIK libsolv uses the Suggests: and Enhances: to pick one of *equally adequate* packages. But we stil need to gain more experience on how well this works. This works flawlessly for rubypick as far as I can say: http://pkgs.fedoraproject.org/cgit/rubypick.git/tree/rubypick.spec#n10 Good to hear! Florian -- Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Charles Peters ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
