[Rpm-ecosystem] Dynamic subpackages
Hello,
As I promised on #rpm.org, I'd like to describe here how we would like to
use potential "dynamic subpackages" feature in Rust packaging.
First of all, rust crates are packages as sources, so there is simply
-devel subpackage containing source code.
That includes Cargo.toml which is the manifest describing what
(dev-)dependencies are, what "features" the crate has and so on.
Those "features" usually mean let's say http2 support, or support for
different compressions, or improved performance or anything what you can
come up with. Apart from triggering some special code paths, most of the
time they add new dependencies. These create dependency loops and huge
bloat of unnecessary dependencies installed on user's systems.
Some time ago I came up with patch for rpmfc which passes package name into
a dependency generators and we were able to split those features into their
own +feature -devel subpackages. This, however, added bunch of boilerplate
into a spec because they have to have the %package, %description, %files
for each feature. And this part can be easily generated from Cargo.toml
manifest.
So for example, if Cargo.toml has following:
[dependencies]
serde_json = { version = "1.0", optional = true }
[features]
json = ["serde_json"]
Then spec should have:
%package -n %{name}+json-devel
Summary:%{summary}
BuildArch: noarch
%description -n %{name}+json-devel %{_description}
This package contains library source intended for building other packages
which use "json" feature of "%{crate}" crate.
%files -n %{name}+json-devel
%ghost %{cargo_registry}/%{crate}-%{version_no_tilde}/Cargo.toml
%package -n %{name}+serde_json-devel
Summary:%{summary}
BuildArch: noarch
%description -n %{name}+serde_json-devel %{_description}
This package contains library source intended for building other packages
which use "serde_json" feature of "%{crate}" crate.
%files -n %{name}+serde_json-devel
%ghost %{cargo_registry}/%{crate}-%{version_no_tilde}/Cargo.toml
All the requires/provides and such would be automatically generated by our
dependency generators.
This currently is being generated by rust2rpm which generates spec file.
Would be nice if we would not have to do a pre-generation of these.
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Required version of rpm?
On Mon, Jul 2, 2018 at 3:56 PM Igor Gnatenko < ignatenkobr...@fedoraproject.org> wrote: > On Mon, Jul 2, 2018, 09:41 Miroslav Suchý wrote: > >> Dne 29.6.2018 v 16:45 Jeff Johnson napsal(a): >> > And -- as I said before -- rpmlib() dependencies and their versions are >> the wrong approach to what you are attempting. >> >> Do you have any other idea how to solve this? >> >> > There is no additional benefit to checking rpmlib() dependencies first, >> or as part of normal dependency processing: in both cases you will get a >> failed operation. >> >> But there is big difference (from UX POV) how it fails. Whether it fails >> with: >> >>Error: Invalid version flag: if >> > > BTW, isn't this message coming from YUM and not from RPM? > Yeah, this message is coming from YUM and not from RPM. So there is nothing to do in RPM. -- -Igor Gnatenko ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Required version of rpm?
On Mon, Jul 2, 2018, 09:41 Miroslav Suchý wrote: > Dne 29.6.2018 v 16:45 Jeff Johnson napsal(a): > > And -- as I said before -- rpmlib() dependencies and their versions are > the wrong approach to what you are attempting. > > Do you have any other idea how to solve this? > > > There is no additional benefit to checking rpmlib() dependencies first, > or as part of normal dependency processing: in both cases you will get a > failed operation. > > But there is big difference (from UX POV) how it fails. Whether it fails > with: > >Error: Invalid version flag: if > BTW, isn't this message coming from YUM and not from RPM? -- -Igor Gnatenko ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] A proof-of-concept for delta'ing repodata
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2018-02-13 at 12:09 +, Michael Schroeder wrote: > On Tue, Feb 13, 2018 at 10:52:14AM +0100, Igor Gnatenko wrote: > > This would "break" DNF, because libsolv is assigning Id's by the order of > > packages in metadata. So if something requires "webserver" and there is > > "nginx" > > and "httpd" providing it (without versions), then lowest Id is picked up > > (not > > going into details of this). > > No, this is not correct. Libsolv doesn't use the Id to pick a package, > exactly to be independent on the package order of the repository. Oh, could you link me source code for this part? I tried to look it up, but haven't found. Thanks! - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqEgP8ACgkQaVcUvRu8 X0z1zw//Vpu6NgZEHZUyes7Bjb5ABmIlP5b9XCo5d0GHAWAfq761eFV4qot/y8H2 ErLDA4+OttOgag+PWNLo5Jpx2pN39r0ccqTWpISfb7lMpumKhlqBAvojSu6tM1nr 9Z3FtBm4EG7pSyjzEQW6Z2BmLovLQOUUncoCR0hbntOB5XK3X/96lkfxmW/8UqRE 62g2SCJHNjz4w74Xc23/ZAkCZtAby6Dw7KJ0DwyPEkl4bRM2GAJhZsnTw8EVHgnH q4v1aSmYezG4GvKNAF/mepMrKJVxMD1JdkaOsFpzaKqFU/QjNpfwDlEGPzMvnCgA ZmVQ7SYMFPGg8KiTUfsIWExm5qTEfmrN0e7RmZgHtFmS/H+h1H40ZUGFfd60k+Q/ pr5z1phc2bZ8iew2SscORj8IYe4xT3oOWbcabLGL1w1aM6QobFckavSL39K1Rpfz YyKGqYOKhENlduhghYvB8+aBM357MVZTrJM5+x9u9NmMiuvH7e/bXQPxhd7LzTCS ESsO7ryWh5kypccHgizrVLKliz+S3Nl+kf9oQLY98gVyxbMNkhfYDkp0gUY46Zvo 0LoTZ8QcajYiryJzOfi4C+7sJpozowxmasHYb15miCspnA1O3PIa82MgrlS77E8B 8gkbCckeGCxaAa3dXa2JgpENBznQ7DgAZaraQT+ZSxb1jF7QPW8= =O1D0 -END PGP SIGNATURE- ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] A proof-of-concept for delta'ing repodata
> They are full of ugly hacks, especially when it comes to parsing the > XML, there's little to no error reporting, and I didn't comment them > well at all, but they should work. > > If all you want to do is download zchunks, you need to run dl_zchunk.py > with the url you want to download (ending in .zck) as the first > parameter. Repodata for various days over the last few weeks is at: > https://www.jdieter.net/downloads/zchunk-test/ You may need to hover > over the links to see which is which. The downloads directory is also > available over rsync at rsync://jdieter.net/downloads/zchunk-test. > > dl_zchunk.py doesn't show anything if you download the full file, but > if you run the command with an old file as the second parameter, it > will show four numbers: bytes taken from the old file, bytes downloaded > from the new, total downloaded bytes and total uploaded bytes. > > zchunk.py creates a .zck file. To group chunks by source rpm in > primary.xml, run > ./zchunk.py rpm:sourcerpm > > unzchunk.py decompresses a .zck file to stdout > > I realize that there's a lot to digest here, and it's late, so I know I > missed something. Please let me know if you have any suggestions, > criticisms or flames, though it might be a few hours before I respond. As being someone who tried to work on this problem I very appreciate what you have done here. We've started with using zsync and results were quite good, but zsync is dead and has ton of bugs. Also it requires archives to be ` - --rsyncable`. So my question is why not to add idx file as additional one for existing files instead of inventing new format? The problem is that we will have to distribute in old format too (for compatibility reasons). I'm not sure if trying to do optimizations by XML tags is very good idea especially because I hope that in future we would stop distributing XML's and start distributing solv/solvx. - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqCtU4ACgkQaVcUvRu8 X0xlcg//eJQy0Qs56p/y011o8r+lGTTrad3Dki4XYB6SwM2ACbEMiWF1gDPtoFCW UtvzNzdzgM8AUuMvZFhByveuM60vbHbkzc3BM5MoumHVfE0Dn/Xih2T9RG4Lbxk5 Th7NuxkGU2oP8byHAMqskXZ+BKjWUE0VKyBi0vtnDMqXFydKFyfkdGiOzGb9QiuH Urvd9BqFZvJ7lNisIwakuXR0geWykKztfOO7vNcnow5yoivljmeIyH5kzDStdJvS YDfRnz9/m8X7iePwRqzElxdS0sNBULDI+Juw+jHBb/h5hg67KfYknJiJv2UshJOl ks+WPjMwloOo7PfoNCdHj5iWC/254u5YgC1doOrlEpXXjizWYryQWl6+TDPoNqFA kjWWvxLu+/6P/wvQdjLWXaZO3wpZrOMypzvrqU9V2C8QVky1yPKnkwKbf/jsP0L6 uVG3p3fmDl84ukpj3igRBmA2EkH/sDTe+KkEPrqZe5aYsSz22bRXLgmYqIPss38R xsnGqdV6pVeSSDVRyxkcpXkmNLA56h9nhqekMRla6O7D+1cnBYrTeAtIWCu/xFl2 zQIUS/9cv5uiWrX+8EP5QTAfbIyp+70Y4AeItG/9NR9CJ4RBDSJPqDguJK6VbIBu nxvNU3/Bam3I+l9LXWN4hQ8Vpei/vWzgo5twlS9fx1rqU0wgMlY= =xHso -END PGP SIGNATURE- ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] [rpm-software-management] LIBDNF - gobject-introspection and reduction of public functions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2017-11-16 at 11:08 +0100, Jaroslav Mracek wrote: > Dear supporters of LIBDNF, You sent to wrong mailing list, replying to proper one here. > > According to a long term plan for LIBDNF, we would like to make LIBDNF > lighter, with supported API. At the beginning we would like to drop a > support of any externally unused functionality or bindings. At the present > time, LIBDNF provides bindings using gobject-introspection for > dnf-context.cpp, dnf-context.h, dnf-repo.cpp dnf-repo.h, dnf-state.h, > dnf-state.cpp, and dnf-version.h, but there is not known anybody that use > it. I would like to open a discussion if there is any reason to support > those bindings for now, because they reduce our flexibility in further > development. > > Additionally I started with reduction of publicly available functions ( > https://github.com/rpm-software-management/libdnf/pull/367) to reduce > maintenance cost and to open a door for further changes without risk of > changing API. The pull-request represents only the first part and it > contains only utils that are only internally used by LIBDNF but unused by > PackageKit, rpm-ostree, or microdnf. Please If any suggestions or issues > with that, please let us know. > > Have a nice day - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIyBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAloNZQAACgkQaVcUvRu8 X0wwJQ/3baiDO/j8/VTwPUXTiL1WN41UVeo2W9glT952/4Hwq1UONWDrUR7UGxAl PL6EOUNDIF9TN2Blg1V3Qlf7hxIs7fZzZTFHuLImj7Da0NsK9Lt2zQJRukWAbO6x sCDToFs9HE8IWYHcBIJEkvM5TzmhAr9dyblOPQl3qLLRDZbIEqLvynR8EggoPM25 VgxSH70zmnljzJkA6pgOYBol0DW3mbDZNZpdjkg/zr7PCv1rAeMDNi0/lzcayGnh WonwRGCq24rSXaLYHGRpsGr37yCMEUvRosVWNf73WrgtoW2jQbdUrqOgz8X4Zx6v K9MDBNUI0C3kqWiU/U7z84jmherh+Usf3WCZWCVeqP8YYcOPYqd6fRU/XwoZvqYG ODXmvxjrdPLBj0gkxzonKOEavrUbpuUT4TLPxqM7+W6a55nEo+ZkZoiQk4WhsYxq GQp4qE6MYb4nT7n/HHIIlNNz4gBKMdYdT5X+m1xCeb4OCfRzrz1E/V9OqZakcRq8 K0FxEazubV6bNh2NsFVDg+TlgkyT83UTOEjzaEXuHn+XxRiEimq6nUADRNNw50lF X7APkZv7ZxbODDw5HW5BZiKdf/fSYyju5ue6le5tjQ+w3aSDqO7a2u0t6ITd9lLH K7d9+bPeJOeqlCRIIl7oroTKHarlb6TM+ZRsgkC9Ds0rlLd2nA== =aPqW -END PGP SIGNATURE- ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] DNF team would like to take over libdnf ownership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2017-10-30 at 11:48 +0100, Daniel Mach wrote: > Hi everyone, > My name is Daniel Mach and I'm leading the DNF team. > > > TL;DR: > > The DNF team wants to take libdnf over and re-start development, > which would > possibly include using C++ (only to limited and reasonable extent). > The goal > is to get existing DNF code into libdnf. The current APIs would > remain > intact. How is this going to work? Do we keep Hy* API around? What about DnfCmd and stuff like this? > We're looking for your use cases. > > > More details follow: > > We are getting requests to implement more features in microdnf, > such as modularity[1][2], unify repo cache and overall business > logic. > Porting big portions of existing DNF code (Python) into a C library > seems to be the only feasible option to avoid code duplication. > > In the first place, we'd like to clarify libdnf ownership and > responsibilities. > Libdnf is currently co-maintained by several teams (DNF, PackageKit, > rpm-ostree), which makes it an unmaintained orphan. > There are gaps in roadmap, development and response time to the > customer > issues. > The code suffers with a technical debt, especially the libhif/hawkey > merge > hasn't been finished. It was bad idea from the beginning. > > From organizational perspective, we are proposing following: > * DNF team to own libdnf and be fully responsible for it. > * DNF team to guarantee existing C and Python APIs. I have HUGE doubts about this. > * DNF team to discuss any API changes with the stakeholders in timely > manner. I would say that each API/ABI change/breakage should follow with SONAME bump and should be mentioned in Pull Request. > * PackageKit to become a libdnf stakeholder. > * rpm-ostree to become a libdnf stakeholder. > > We are looking for a way how to boost the development speed by using > a more > high-level programming language than C. We are considering C++ at the > moment, > because it offers some features we (mainly Python programmers) would > appreciate, > including strongly typed lists and dictionaries, less work with > pointers and > last, but not least - native objects. It also allows us to wrap and > re-use > existing C code without major changes. Does it mean you will be wrapping std::vector and such to GPtrArray? Are you going to make some separate library for such conversions? Will you use glibmm? > > Short-term plan: Fix libdnf technical debt > * Finish libhif and hawkey merge. > * Remove unused code. > * Fix code duplicates. > * Hide private functions which were published by mistake. > > Mid-term plan: > * Merge DNF Base class with libdnf's context. > * Re-shuffle existing C code into new structures, but still keep > existing > APIs. That doesn't make any sense to me. > * Implement modularity[1] > > Long-term plan: > * Full rewrite/cleanup > * Move major part of DNF's code into libdnf > * New, well-defined, fully supported API > > The Holy Grail: > * libdnf becomes "The Software Management Library" > * libdnf has fully documented and tested API > * libdnf has bindings to infinite amount of languages :) Note that it is already through GObject Introspection. > > I'd like to ask you for your feedback on the plan. > If you have any use cases you'd like implemented, please open an > issue[3] or > a bug[4]. > I understand that the C++ part sounds controversial, but as long as > we keep > the > C API available and intact, nothing should change for the existing > users. > Please keep the discussion technical. > > > thanks, > Daniel > > > [1] https://docs.pagure.org/modularity/ > [2] https://github.com/rpm-software-management/dnf/tree/wip/modularit > y > [3] https://github.com/rpm-software-management/libdnf/issues > [4] > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=li > bdnf > ___ > Rpm-ecosystem mailing list > Rpm-ecosystem@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAln3C18ACgkQaVcUvRu8 X0yG4Q/+Pp3DnzoTQ8YhfZw22mzw8TorzDQbTwsb39B+qZ3mw9lrKQdlyeQOd2fe XNyujq67x7WVUq8xrxCGFZ3PWaag1Zn9t9//mt1W2iVlq2dOhLeToCPlb1ls8YCy 7SWEFy7sklVHOBbUNiNdn9UBufhwd4D8MVCxW6w+GDAMyMu2WE2lAHJ0wISyzcKW h2zmN66LDZ0FQtygfZ7h7v6h2G27GmCQ3EuInOG0p47i/AxkHoq2l9bf/uFkfxrH OIUfXsYFAJbchKlLSGxzFZfNuESZRLWj8cSIp1DHkkSDBkGa0Ldz+heujlCjBKrb AvA59xinXYV1KdHBMXiYO8oneFxojkSGBH8vI26Qm5ko05b88HxM2RH53BHUGbFi HYkKgk9ejEMlyQwYvfRbXzdgh0wU38VX4bKooMVPy3YYaoAqNBt4I4T+0L9uNJh6 EOLXfOsX8RJc+5Hr6iLMJq7rLn4qeO1xsr68lHRDzoZyvMI95qPVLqYxM4/40PMq EwZTiLqkdZGdBnkLxlkD6MKQ
Re: [Rpm-ecosystem] Why should Copr build service parse %name from spec file for dist-git import
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2017-08-29 at 12:37 +0200, Miroslav Suchý wrote: > Reposting original message as Pavel is not approved member of this > mailing list. Thanks! > > Dne 28.8.2017 v 17:46 Pavel Raiskup napsal(a): > > Hi all! > > > > In Copr project, we try to solve interesting question which is > > worth > > asking wide and experienced audience. > > > > Copr service maintains it's own dist-git server; that means that > > each > > build request needs to be first imported into dist-git (sources > > uploaded > > and spec/patches committed to git). Then, the binary RPMs are > > built > > almost solely from the dist-git sources (well, since you can opt-in > > an > > Internet access, and copr (imo a bit mistakenly) tries to download > > the > > not-yet-downloaded tarballs, this rule is not enforced). > > > > Anyways, consider that you have an upstream project having specfile > > named > > `blah.spec`, which has inside the statement "Name: python- > > %pypiname". > > Copr dist-git automation downloads your project, takes this spec > > file and > > tries to decide "which dist-git module should I import this spec > > file > > into?". So, where should we import? > > > >Option #1 -> import into blah.git (since that's blah.spec) > >Option #2 -> import into python-blah.git (since %name expands to > > python-blah) > >Option #3 -> refuse to build the package > > > > To be honest with you all, I'm all for #3 (but we are proven we can > > not do > > that, that's too restrictive and a lot of people will complain, > > even if > > their packages don't comply with guidelines). > > So, I'm personally picking #1 because that's trivial and 100% > > deterministic. Are there any reasons to pick #2? I definitely dislike option #2 which is currently in production. Also it requires spec to be able to be parsed by some RPM which might be older than required (hello weak/rich dependencies). In theory, name also can expand differently on different versions of distros (e.g. because of some EPEL policies, there is some macro which changes name/paths to different one on EPEL).. It seems to be just over- engineered without any benefit. Option #3 doesn't fit due to same problems, but it is even worse because it is breaking builds. So I'm all in for Option #1! Also I hope it will get versions of packages back into COPR... Look at https://copr.fedorainfracloud.org/co prs/g/rust/playground/build/585107/ Version: - To me, this is just regression. > > > > Pavel > > > > ___ > Rpm-ecosystem mailing list > Rpm-ecosystem@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmlSBkACgkQaVcUvRu8 X0yFzQ/9EJke1WiGd8iMr+roRlo7ABkQwG5aIfNZ4J2eoj43t1kkKOt7A0CKWcL5 BSHccYEt4zRqPbNm+dl574xeTyDTbSq2V3HU/sNihEkaWGITxuOAybMQSNYcFNyL AOJnLFWa/AwsQN5GL5vWuQWmnzft0BqWH+cIblWgAT0mHAWYumRd27YGJ0qxUQBP KwCVX0cuA297S/K06yPUGRUpK4pFdAl0T0aFM/18kDN5huvJrB9mA+T4L+55VLN9 6dtPy/0gKWzKZcEphC7y2Msfm1zKsukFLjkPpwkDnybHMWgnW496904wOV6SchsL Mv7cdoqYDYt0fAetSQCY/t46ydZlGjApwFY47Z4ZUIyg01Bo1tB18QqS3Wm1lOQU K4Vok0Vs8JvBAESmKQH9HUx84nDFiRn9+xiS9pp/u7ShOjE+Q0JnDBwjAyPBUHGG K9REXeocV87GPwAzXHU2pcWtj5U27Ff7eTbuS2qlJJKtIREDdAaxQK1nRr9Zr52g zy5p5uVT/2K2BZiBhzFYwWQYV6Zq8OtG2jCfRn6lOXnOXvzrxyu3dLuOQVGRsg6g c4Pqb9/W93ouHphrkomVS7d5OeejecUvp0dYnJe05qWXZFOwCqfON7xRc4RGjAjE dZHkYQg+x2rOP5DarGSCT/ojlD7F2/SLx3i8k2OCnCiRVdI2M1c= =6+/w -END PGP SIGNATURE- ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Why should Copr build service parse %name from spec file for dist-git import
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2017-08-29 at 11:15 +0200, Miroslav Suchý wrote: > Dne 28.8.2017 v 17:46 Pavel Raiskup napsal(a): > >Option #2 -> import into python-blah.git (since %name expands to > > python-blah) > > This option is currently used everywhere. The question is why? Is it > just easier? Or are we just afraid to enforce spec > file name rule? Somehow I miss primary message... So what's the original question / problem? > Mirek > ___ > Rpm-ecosystem mailing list > Rpm-ecosystem@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmlOkwACgkQaVcUvRu8 X0wg0g//QZZYA42DcFuKgJ9CFWaAZQJ7Kz+CGlYO2HJQLB63hwj5ZlkoX1iyFF8Q aNOJTOxE7aPKxuH+jplpS0GRzrqA2FHh13xNwXiFdaLZwao/H4BjwN8dIOQIYE0Y c/u7yzlYWec1htp4ZAMMGWfX1HMsjuzoV0Seb66aiuV2g0AT5e6SO1WI+UXm1+QK ZYKqhhNRAsr0hfJieyDPG6ac3QPVqrfgf9olWeLJLd1eSAD8KKwpxLvyrSF9KnWK 0e//9NOsJkKYl2Qp5zjrbtdLQqDYT5bbQpL17tnpkqv8lTV+ATJf1gZTjM1tHRb/ /LwGJWV8JwI4H7tp0fnIPw2n/8jUe2M0t1fXlffTHwMBnUuO756FRxMxWYZ3o3O/ r8abvhq9GjTSg4wBCCXsybLFUDpQSwTQayPHZbtrXpeISMYX03yXCHEufGEmgJXy VpD3fSFwyM5yBqYaqMGNnbV1vZVyZ/4UL/aYfsnJ9NFjke6gq24GQnZE5AOAch2z u8UmgPdPT3nGiePVS2CbKI6bsspTsBBcbWvojbbM63dWtoZStcIeNiLgM1rhSPjE V4SR6o86PRQbG/dl+SjcIfPlxj2lL8GNJFtUYhV/3ANPmjdnKmxdQK3TrhIar3Kg x7Yqe1zf6nDB4CBvjccNtyJGAFrbIGTgo/8+2R5mtbesQap+el4= =Krld -END PGP SIGNATURE- ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
[Rpm-ecosystem] Automatic BuildRequires
This topic is not very much interesting for C/C++/D/etc. languages, but very interesting for Python, Ruby and Rust ecosystems. In those ecosystems you can get build-time and test-time dependencies very easily since metadata is pre-populated (doesn't matter how) and you just need to parse it, but RPM doesn't support generating BuildRequires. As we discussed some time ago with Panu and Florian on IRC this task splits to 2 different blocks: 1. Pre-BuildRequires -- everything what needs to be installed in order to unpack archive and parse metadata 2. Make building of SRPM a bit more tricky: first time to build something what can gather builddeps and then generate full SRPM with all that stuff. I was thinking a bit if we should really make different section for only for generating builddeps (as Panu was asking) and I think it's not needed and we can (or probably even should) reuse -- for example, upstream provides wrong metadata (redundant requires or very strict version which you want to relax), you do sed/patch in %prep and it should be both same for BuildRequires generation and for real build. Another question here as well is how do you generate test builddeps: since we don't have BuildRequires(check), we probably would need to have BuildRequires and TestRequires generator... but I'm not sure how to wrap it properly. Thoughts? -- -Igor Gnatenko signature.asc Description: This is a digitally signed message part ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
[Rpm-ecosystem] Boolean dependencies vs self-provides (for rust "features" support)
```toml
[dependencies]
bitflags = "~0.7"
ansi_term = { version = "~0.9.0", optional = true }
term_size = { version = "~0.2.0", optional = true }
libc = { version = "~0.2.9", optional = true }
[features]
default = ["color", "wrap_help"]
color = ["ansi_term", "libc"]
wrap_help = ["libc", "term_size"]
```
Since we are packaging source code, -devel package will have `Requires:
crate(bitflags)`. But applications (which are built out of this sources
statically) can request features which this source is exposing and it
means that it should pull additional dependencies.
Syntax for such dependencies is like:
```toml
[dependencies]
clap = { version = "2.19.2", features = ["yaml"] }
```
Obviously, first thing which is coming to mind is to specify provides
for features and use rich dependencies for requirements, something
like:
```
Provides: crate(clap)
Provides: crate(clap)(color)
Requires: ((crate(ansi_term) and crate(libc)) if crate(clap)(color))
Provides: crate(clap)(wrap_help)
Requires: ((crate(libc) and crate(term_size)) if
crate(clap)(wrap_help))
```
But it doesn't work since it works the RPM thinks that crate(clap)(xxx)
is going to be installed (since it's provided by same package) so it
requires other packages to be installed as well which is something not
what we want.
Probably for now sane way would be just require all optional packages
to cover *all* features which package provides, but it means that
builds will be slow because they would need to pull a lot of packages
always.
P.S. I omit version stuff to make examples more easy.
P.P.S. ignore `default` feature for now since I'm not sure how exactly
it works in rust/cargo ecosystem at this moment.
--
-Igor Gnatenko
signature.asc
Description: This is a digitally signed message part
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] lightweight docker container + microdnf in F25
On Fri, 2017-01-20 at 23:40 -0500, Dusty Mabe wrote: > I have created a lightweight container image for fedora rawhide [1] > based on > microdnf. It would be great if we can get microdnf into F25 so we can > have an image there as well and go ahead and start using it and > have some of the community testing it out. If I understand correctly > there are some technical limitiations with providing microdnf in > Fedora > 25 because of library changes, etc. Could we possibly just bundle > those > dependencies in microdnf in Fedora 25 so we can have it there as > well? > In 25+ we won't need it to be bundled because of library changes, > etc.. so > this would be only be a hack temporarily. No bundling and no hacks, please ;) Here you go: https://bodhi.fedoraproject.org/updates/FEDORA-2017-096c58 386b > > Thanks! > Dusty > > PS - for experimentation you can pull the image from > "dustymabe/docker-min" > > [1] https://pagure.io/fedora-kickstarts/pull-request/120 -- -Igor Gnatenko ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
[Rpm-ecosystem] [RFC] Standardizing RPM macro for out-of-tree builds
Hi, during last FPC meeting we agreed[0] that we need some standardization of macro related to builds where builddir != srcdir (and with possibility to make it builddir = srcdir). I was working to make guidelines for ninja and meson. For ninja it doesn't matter from where you build (it's like make), but meson itself accepts ONLY out-of-tree builds. Would be nice to get system-wide (rpm-wide?) macro which stands for: 1) source directory where CMakeLists.txt/meson.build/configure are 2) build directory (I think _target_platform is a good candidate) to make out-of-tree conversion to in-tree, you do the RPM variable override. For example, in openSUSE it's defined in cmake[1] as __builddir and __srcdir. Ideas, suggestions are appreciated! [0] https://meetbot.fedoraproject.org/fedora-meeting-1/2016-10-13/fpc.2016-10-13-16.00.log.html [1] https://build.opensuse.org/package/view_file/openSUSE:Factory/cmake /cmake.macros?expand=1 -- -Igor Gnatenko ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Special meaning of "+" (?) separator
On Mon, Sep 12, 2016 at 4:36 PM, Panu Matilainen <pmati...@laiskiainen.org> wrote: > On 09/12/2016 05:31 PM, Igor Gnatenko wrote: >> >> On Mon, Sep 12, 2016 at 4:27 PM, Panu Matilainen >> <pmati...@laiskiainen.org> wrote: >>> >>> On 09/12/2016 05:18 PM, Panu Matilainen wrote: >>>> >>>> >>>> On 09/12/2016 03:10 PM, Neal Gompa wrote: >>>>> >>>>> >>>>> On Mon, Sep 12, 2016 at 8:07 AM, Florian Festi <ffe...@redhat.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> Changing the way + is treated in version compare is really a bad idea. >>>>>> So this feature would need a new char that is currently not permitted >>>>>> in >>>>>> versions. Candidates include: #, ^, @, §, $, ? >>> >>> >>> >>> Other possible candidates would be |, %, &, ! and *. >> >> | is shell-ish >> % is already taken by RPM >> & is shell-ish >> ! is shell-ish >> * is shell-sih > > > Yes, but then both tilde and caret have a special meaning in shell as well. There is some escaping done for that (/me checked with rpm -ivh). > > ?, *, & and | certainly seem like begging for trouble, others to lesser > degree. with ! there is no escaping (I'm not sure it's even possible). > > > - Panu - > > ___ > Rpm-ecosystem mailing list > Rpm-ecosystem@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem -- -Igor Gnatenko ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] Special meaning of "+" (?) separator
Attaching patch to what I came up.
If everything looks good, I will write same for libsolv.
On Sat, Sep 10, 2016 at 12:58 AM, Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl> wrote:
> On Fri, Sep 09, 2016 at 05:23:26PM -0400, Neal Gompa wrote:
>> On Fri, Sep 9, 2016 at 4:24 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
>> > Hi,
>> >
>> > during process of getting tilde approved in Fedora Packaging
>> > Guidelines we realized that we need some special handling for
>> > separator (most probably) "+".
>> >
>> > Some examples (left is what expected, right is what current situation):
>> > 1.0+ > 1.0 | 1.0+ == 1.0
>> > 1.0+20160101git < 1.0.1 | 1.0+20160101git > 1.0.1
>> >
>> > During long discussion at #rpm.org on freenode with Florian and Panu:
>> >
>> > 1. Florian didn't like to change behavior of "+" as it's already
>> > allowed character and people might expect it to do something
>> > different.
>> > 2. From alternative symbols we needed to choose from: "@", "#", "^"
>> >
>> > After thinking more about problem I realized that we probably just
>> > change behavior of "+".
>>
>> Yes, this is the right way to go, as we don't need more "specialness"
>> and it's relatively intuitive to indicate + as the
>> checkout above it.
>
> +1
>
>> > Some questions are still in my mind:
>> > * vercmp: 1~ ? 1+
>>
>> I'm not sure here. Normally, you use "1~" to indicate an all-inclusive
>> set (pre-release, release, and post-release), as opposed to "1" (which
>> would include only release and post-release).
>>
>> Strictly speaking 1~ < 1+ in comparison, as the tilde operator pushes
>> it down and the plus operator would push it up.
>
> Yes, I don't think it can be any doubt here. ~ is defined so that
> 1~ < 1, and 1 < 1+, so 1~ < 1+ by transitiveness of unequality operations.
>
>> > * How "+" should be handled in (Build)Requires?
>> > * BuildRequires: foo == 1+ should match 1+, 1+git, 1+whatever ?
>>
>> I'm not sure exactly how this should be handled... Probably 1+?
>
> Why should we introduce any special behaviour here? Normally the ==
> operator requires an exact version match, and version 1+ !=
> 1+whatever, just like 1 != 1whatever, so 1+ should only match 1+. If
> you want to match things starting with 1+, just write BuildRequires
> foo >= 1+ .
>
>> > * BuildRequires: foo >= 1 should match 1, 1.1, 1+git, 1.1+whatever ?
>>
>> Yes.
>>
>> > * BuildRequires: foo < 1+ should match 1, 1~git, 0.whatever ?
>>
>> Yes.
>
> Yes, yes.
>
> Zbyszek
> ___
> Rpm-ecosystem mailing list
> Rpm-ecosystem@lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
--
-Igor Gnatenko
diff --git a/lib/rpmvercmp.c b/lib/rpmvercmp.c
index b3d08fa..0d59d96 100644
--- a/lib/rpmvercmp.c
+++ b/lib/rpmvercmp.c
@@ -33,8 +33,8 @@ int rpmvercmp(const char * a, const char * b)
/* loop through each version segment of str1 and str2 and compare them */
while (*one || *two) {
- while (*one && !risalnum(*one) && *one != '~') one++;
- while (*two && !risalnum(*two) && *two != '~') two++;
+ while (*one && !risalnum(*one) && *one != '~' && *one != '+') one++;
+ while (*two && !risalnum(*two) && *two != '~' && *two != '+') two++;
/* handle the tilde separator, it sorts before everything else */
if (*one == '~' || *two == '~') {
@@ -45,6 +45,16 @@ int rpmvercmp(const char * a, const char * b)
continue;
}
+ if (*one == '+' || *two == '+') {
+ if (*one == '\0') return -1;
+ if (*two == '\0') return 1;
+ if (*one != '+') return 1;
+ if (*two != '+') return -1;
+ one++;
+ two++;
+ continue;
+ }
+
/* If we ran to the end of either, we are finished with the loop */
if (!(*one && *two)) break;
diff --git a/tests/rpmvercmp.at b/tests/rpmvercmp.at
index 2a25bdd..784a60c 100644
--- a/tests/rpmvercmp.at
+++ b/tests/rpmvercmp.at
@@ -78,17 +78,17 @@ RPMVERCMP(2_0, 2.0, 0)
dnl RhBug:178798 case
RPMVERCMP(a, a, 0)
-RPMVERCMP(a+, a+, 0)
-RPMVERCMP(a+, a_, 0)
-RPMVERCMP(a_, a+, 0)
-RPMVERCMP(+a, +a, 0)
-RPMVERCMP(+a, _a, 0)
-RPMVERCMP(_a, +a, 0)
-RPMVERCMP(+_, +_, 0)
-RPMVERCMP(_+, +_, 0)
-RPMVERCMP(_+, _+, 0)
-RPMVERCMP(+, _, 0)
-RPMVERCMP(_, +, 0)
+RPMVERCMP(a., a., 0)
+RPMVERCMP(a., a_, 0)
+RPMVERCMP(a_, a., 0)
+RPMVERCMP(.a, .a, 0)
+RPMVERCMP(.a, _a, 0)
+RPMVERCMP(_a, .a, 0)
+RPMVERCMP(._, ._, 0)
+R
[Rpm-ecosystem] Special meaning of "+" (?) separator
Hi, during process of getting tilde approved in Fedora Packaging Guidelines we realized that we need some special handling for separator (most probably) "+". Some examples (left is what expected, right is what current situation): 1.0+ > 1.0 | 1.0+ == 1.0 1.0+20160101git < 1.0.1 | 1.0+20160101git > 1.0.1 During long discussion at #rpm.org on freenode with Florian and Panu: 1. Florian didn't like to change behavior of "+" as it's already allowed character and people might expect it to do something different. 2. From alternative symbols we needed to choose from: "@", "#", "^" After thinking more about problem I realized that we probably just change behavior of "+". Some questions are still in my mind: * vercmp: 1~ ? 1+ * How "+" should be handled in (Build)Requires? * BuildRequires: foo == 1+ should match 1+, 1+git, 1+whatever ? * BuildRequires: foo >= 1 should match 1, 1.1, 1+git, 1.1+whatever ? * BuildRequires: foo < 1+ should match 1, 1~git, 0.whatever ? Thoughts? Suggestions? -- -Igor Gnatenko ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Re: [Rpm-ecosystem] RPM in ALT Linux (4.0.4 vs 4.13)
On Sun, Sep 4, 2016 at 1:28 PM, Ivan Zakharyaschev <i...@altlinux.org> wrote: > Hello! Hi, > > On Sat, 3 Sep 2016, Neal Gompa wrote: > >> I saw you guys listed as the most recent ones to change the rpm >> package in ALT Linux, and I was wondering if you guys had contemplated >> upgrading from rpm 4.0.4 to rpm 4.13? > > > glebfm@ and legion@ are busy now with this. > https://lists.altlinux.org/pipermail/devel/2016-July/201603.html > > They could give most details about this process. > > The first thing to do on this way was to rebase many ALT's features[1] onto > rpm(-install)-4.13. (Not yet features relevant for rpm-build.) > > [1] https://www.altlinux.org/Rpm-4.13 > >> If so, why haven't you? What's holding you back from upgrading? I'd > > > Apart from the first important step (rebasing ALT's rpm-install) which has > been done and is ready for testing, there are things would hold us back from > putting the new version into ALT Sisyphus: > > those packages which use librpm and/or access RPM's db will have to be > adapted for the new version. (The first one, of course, is APT; then, there > are some Perl bindings actively used by the tools for automatic package > analysis, modification, submission; perhaps, some more, I don't know the > list of things that hold this back well, but other involved people could > tell you more.) > >> like to see the ALT Linux rpm maintainer team be involved in upstream >> rpm.org development, as I'm sure your perspective would be valuable to >> ensure a vibrant ecosystem around rpm. > > > As said, there are a few ALT-specific nice, important and non-trivial > features in RPM, which would always require maintaining a separate fork > unless they are taken up by another RPM project, say, the rpm-4.13 project. > Then the forces could be joined. Why don't you propose patches to RPM upstream? > > One of these features is the support for set-versions (the <= relation, > which is used to constrain Requires/Provides, which would behave not like a > linear order, but like inclusion of sets), developed by at@ in the past. > Now, he has announced that he is developing an enhanced varaint of this > feature and could tell the details about the current developments to those > who are interested. > (https://lists.altlinux.org/pipermail/devel/2016-July/201614.html : support > for prototypes/signatures similar to C++ mangling, but for C). > > at@ has pointed to his new work at https://github.com/svpv/rpmss -- > https://lists.altlinux.org/pipermail/devel/2016-August/201701.html . At the > same time, at@ shared his belief that if there is some code in ALT's RPM > which was once written and works correctly since then, there will be no need > to put efforts into maintaining it; and so, he sees no justification in the > complex work of rebasing onto rpm-4.13 because this would not save us any > future efforts in maintaining ALT's RPM compared to the current situation. > (Zero efforts if the current code of RPM works correctly.) > > glebfm@ -- Gleb Fontengauer-Malinovskiy > > legion@ -- Alexey Gladkov > > at@ -- Alexey Tourbin > > community-en@lists -- a mailing list for the community around ALT for > discussions in English > > -- > Best regards, > Ivan > > > ___ > Rpm-ecosystem mailing list > Rpm-ecosystem@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem -- -Igor Gnatenko ___ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
