scripts/pythondistdeps: Only add setuptools requirement for egg-info packages.
This should address issue #954
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/973
-- Commit Summary --
* scripts/pythondistdeps: Only add
Squashed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/951#issuecomment-558488170___
Rpm-maint mailing list
This branch was intended to address issue #881 but I also handled #612 and some
other fixes. Please let me know if youd prefer these commits in
individual PRs.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/951
-- Commit
@encukou I have no illusion that this change is pretty. :)
I will say that if you have time to write an outline of what you'd like to see,
I can put some time into further improvements. For example, I don't know what
you have in mind when you say "strictly standard-based implementation"
--
@gordonmessmer pushed 1 commit.
9f69722fa70c6a06bb15a090abfc89dba2d63e68 Import parse_version with other
pkg_resources imports.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Thanks, @encukou
If this PR looks good to you all, then let's merge and close it, and continue
discussion in issues on the convert-440 project. Miro has a couple open now.
If I get that code into a condition where we're happy with it, then I can add
unit tests and then work on integrating
This should resolve #981
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/982#issuecomment-568068686___
Rpm-maint mailing list
```
[gordon@vagabond:~/git/rpm]$ find /home/gordon/git/molecule-root/ | python3
~/git/rpm/scripts/pythondistdeps.py -R
python(abi) == 3.7
python3.7dist(ansible) >= 2.5
(python3.7dist(ansible-lint) >= 4.1.1a2 with python3.7dist(ansible-lint) < 5)
python3.7dist(cerberus) >= 1.3.1
gordonmessmer commented on this pull request.
> @@ -269,7 +269,10 @@
spec_list.append('{n} >= {v} with {n} <
{vnext}'.format(n=name, v=spec[1], vnext=next_ver))
else:
spec_list.append('{} {} {}'.format(name, spec[0], spec[1]))
-
@gordonmessmer pushed 1 commit.
d8d1da567caeb7ff7e1f90a2a80beba21aa2d996 scripts/pythondistdeps: Only print
rich dep list when required to.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@Conan-Kudo Seems only right that I fix what I broke. :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/982
-- Commit Summary --
* scripts/pythondistdeps: Only print rich dep list when required to.
-- File Changes --
M scripts/pythondistdeps.py (5)
-- Patch Links --
@ignatenkobrain I started a repo to flesh out some of the requirement
conversions from python dist tools to rpm. It doesn't mangle versions right
now, but maybe you could open an issue there and describe what should happen?
https://github.com/gordonmessmer/pyreq2rpm/
--
You are receiving
gordonmessmer commented on this pull request.
> +version_id = version_id[:-2]
+version = RpmVersion(version_id)
+lower_version = RpmVersion(version_id).increment()
+else:
+version = RpmVersion(version_id)
+lower_version = version
+return '(%s < %s
@gordonmessmer pushed 1 commit.
dfd1724b974a05da079a1a5ba5f45c14a9212bfb scripts/pythondistdeps: Print
Provides-Extra entries for Python packages.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
gordonmessmer commented on this pull request.
> +else:
+rpm_epoch = ''
+while self.version[-1] == 0:
+self.version.pop()
+rpm_version = '.'.join(str(x) for x in self.version)
+if self.pre:
+rpm_suffix = '~%s' % ''.join(str(x)
@gordonmessmer pushed 1 commit.
12100cc343050ab69048796156bcc46d6fcdde97 scripts/pythondistdeps: Improved
python version and operator handling.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
I've pushed a modified change that uses a slash separator, like the rust
generator does. It also adds the version to extras:
```
$ find /home/gordon/git/molecule-root | python3 pythondistdeps.py -P
(python3.7dist(molecule) == 3.0a5.dev15+gec8c85e9.d20191124)
(python3.7dist(molecule/docker) ==
gordonmessmer commented on this pull request.
> +version_id = version_id[:-2]
+version = RpmVersion(version_id)
+lower_version = RpmVersion(version_id).increment()
+else:
+version = RpmVersion(version_id)
+lower_version = version
+return '(%s < %s
> Note that the subpackages approach has a problem if an extra goes away and it
> was installed on user machine.
Maybe not a *huge* concern... setuptools' documentation tells developers not to
do that.
Does rpm offer an interface to determine whether or not a dependency expression
is valid, either on a command line or in python's "rpm" module? Or is building
an rpm the only available test?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
The RPM Python API would be ideal if I could use it to determine if an
expression were valid. I would think dsSingle would do that, but it does not
seem to care whether the second arg is a valid expression or not.
--
You are receiving this because you are subscribed to this thread.
Reply to
This change handles a number of additional quirks in converting python
packaging requirement expressions to rpm, including handling .* in various
operators and handling pre and post releases.
For example, comparing the output of pythondistdeps.py -R for
molecule before and after this patch:
> You probably should look what rust packages are doing :)
I'd be happy to. Do you have a pointer to where I should start?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Also, we have a chunk of unused logic for Extras in here... Do we want to do
> something with it?
I'm uncertain. It looks like that was started as a means of packaging the
optional components in separate rpm packages. If that is completed, then it
would be necessary to relocate the code in
> How did you come up with the notation?
"runtime(x::y)" is already used by perl packages (though not describing exactly
the same thing), so I know that rpm will accept it. That also means it's
mostly consistent with an established notation. As far as I know, the
double-colon will never
> There is no way to conditionally provide something, unfortunately
I may be mistaken, of course, but it looks like the extras reflect what was
built and installed. What would need to be conditional at the point when we're
examining the buildroot to determine what's there?
--
You are
gordonmessmer commented on this pull request.
> +else:
+rpm_epoch = ''
+while self.version[-1] == 0:
+self.version.pop()
+rpm_version = '.'.join(str(x) for x in self.version)
+if self.pre:
+rpm_suffix = '~%s' % ''.join(str(x)
gordonmessmer commented on this pull request.
> +version_id = version_id[:-2]
+version = RpmVersion(version_id)
+lower_version = RpmVersion(version_id).increment()
+else:
+version = RpmVersion(version_id)
+lower_version = version
+return '(%s < %s
…ges.
For discussions sake: should pythondistdeps.py print the
extras in its Provides output, so that we can properly Require
those features in dependent packages?
For example:
```
$ find /home/gordon/molecule-root | python3 pythondistdeps.py -P
(python3.7dist(molecule) ==
gordonmessmer commented on this pull request.
> @@ -178,8 +178,10 @@
depsextras.remove(dep)
deps = depsextras
# console_scripts/gui_scripts entry points need pkg_resources from
setuptools
-if
I've pushed a change that should resolve the issues with trailing .0 versions.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@gordonmessmer pushed 1 commit.
e95e3bc68257d81cc5122079de308e6a96ba4bf9 Leave trailing .0 in the version
until the convert function is called.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
I removed one more instance of stripping ".0" that doesn't have an effect on
the output. This one when printing provides.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@gordonmessmer pushed 1 commit.
6da249c4ca8731e5b9f7722924b855500798c2b2 Leave trailing .0 in the version
until the convert function is called.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Squashed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1015#issuecomment-611878617___
Rpm-maint mailing list
Please let me know if this PR needs any additional changes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1184
-- Commit Summary --
* Handle all-zero versions without crashing.
-- File Changes --
M scripts/pythondistdeps.py (2)
-- Patch Links --
I'd be happy to help fill those tests out. @torsava let me know where your
work is at now, if you'd like.
This change incorporates code from https://github.com/gordonmessmer/pyreq2rpm/
which has a test suite of its own.
--
You are receiving this because you are subscribed to this thread.
I know that Miro has expressed concerns about splitting language-specific tools
into different repos because it tends to be more difficult to get those tools
into broad use if they're separate releases. Perhaps separate git repos and a
unified release are not mutually exclusive, though.
What
@gordonmessmer pushed 1 commit.
2d103575f57baca8e8d08dd032a4b2054b7fcb25 scripts/pythondistdeps: Improved
python version and operator handling.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Rebased. Probably ought to have done that regardless. :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Speaking only for myself: I added some tests that compared the results of
setuptools to rpmdev-vercmp. The effect of this change can be seen in the
change to tests/test_convert.py here:
https://github.com/gordonmessmer/pyreq2rpm/pull/7
--
You are receiving this because you are subscribed to
This change better reflects the behavior of setuptools in situations that are
processed successfully, but not covered in the specification.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1299
-- Commit Summary --
* Sync
Closed #1014.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1014#event-4750645666___
Rpm-maint mailing list
Looking at the contents of /usr/lib64 on my local system, I see some cases that
look like developers not versioning their so _at all_ (e.g.
libasprintf.so.0.0.0, and 144 others). But that's about 7% of all shared
object files.
Generally: that sounds like it'd be a major improvement, with
@gordonmessmer commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with
@gordonmessmer pushed 1 commit.
c54b9218b9b0aafb643eaa5afdaf490ffb6c1107 Review fixes.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/369bf9b91e5e85f00f7a925e152137598fbed1ba..c54b9218b9b0aafb643eaa5afdaf490ffb6c1107
You are receiving this because you are
> calling rpm from within a generator has always been considered a bad thing to
> do
Understood. I don't think this PR is the _right_ way to solve this problem.
It's just a quick mock-up; I expect to throw it away and do something "the
right way" later.
My hope is that we can discuss
@gordonmessmer commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with
@gordonmessmer commented on this pull request.
> @@ -0,0 +1,15 @@
+#!/bin/sh
+
+version_deps () {
+ while read dep
+ do
+ if [[ "${dep}" =~ ^[^\(]*\(\) ]] && rpm -q --whatprovides
"${dep}" &> /dev/null
+ then
+ printf "($dep with
> Oh, one more caveat: if the shared library uses symbol versioning, exclude it
> from the new generator.
Understood. This mock-up only applies the externally-enhanced version info to
shared objects that don't provide versioned symbols, and any future work would
do the same.
--
Reply to
> The whole point of sonames is that it's NOT tied to versions but the soname
> abstraction, and this kind of dependency breaks that point.
I think "the point" is that binaries should not need to re-link when a shared
object is updated with a backward-compatible version.
However, because rpm
> I can think of one real-world case this would have broke: the SDL ->
> sdl12-compat transition
Would that have required Fedora to do more than either [bump the so
version](https://github.com/libsdl-org/sdl12-compat/commit/883b629995e998e04b2ccd80a2c3ada46b0ce093)
or, worst case, manually add
> (libcurl.so.4()(64bit) → libcurl.so.4()(64bit) >= 4.8.0)
I'm going to start work on an implementation of this soon. I've been looking
over elfdeps.c and thinking through implementation details, yesterday.
One thing that comes to mind is that while the Provides: change would be
backward
> to deal with weaknesses in the Debian's packaging system
I'm curious... do you have a reference that describes those weaknesses? (I
have very little experience with dpkg)
> Bumping the soversion would have been a big deal, since it's an ABI break
I'm not suggesting bumping the major
For shared objects without versioned symbols, this additional information
allows rpm to track minor-version dependencies.
The initial version of this PR updates the external dependency generator, so it
will only affect packages that set `%global _use_internal_dependency_generator
0`, so its
@gordonmessmer pushed 1 commit.
369bf9b91e5e85f00f7a925e152137598fbed1ba Enhance requires with version
information from the build root.
--
View it on GitHub:
This version seems to work as intended. It's more complex than I'd like, but
still probably better than parsing the output of ldd.
```
$ elfdeps --requires --libtool-version-fallback /lib64/libsoup-3.0.so.0
libz.so.1(ZLIB_1.2.0)(64bit)
libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)
```
libgssapi_krb5.so.2()(64bit) >= 2.2
libz.so.1()(64bit) >= 1.2.12
```
Well... almost as intended. Those two are unnecessary since the libraries
provide versioned symbols, and shouldn't have additional version information.
I'll figure out how to detect and skip that case. In the mean time,
If we assumed that the SHT_GNU_verneed header appeared before SHT_DYNAMIC, then
when processing the latter, we could loop over the existing ei->requires and
look for elements that start with the same filename, and skip the libtool
version lookup if one is found.
The only problem is that I
```
$ elfdeps --requires --libtool-version-fallback /lib64/libsoup-3.0.so.0
libz.so.1(ZLIB_1.2.0)(64bit)
libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.6)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
@gordonmessmer pushed 1 commit.
0af21b5ca6137983cb0eeea60b1d874302e6f67e Avoid using fallback version when
versioned symbols are found.
--
View it on GitHub:
@gordonmessmer pushed 1 commit.
2075c5ea488bb45196c89665f203cf938e63b841 Enhance requires with version
information from the build root.
--
View it on GitHub:
@gordonmessmer pushed 1 commit.
2ec718ef2f5794c67bdfed8fd915033d472f21e5 Run dlmopen in a child process.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/41da0a2924d11b23a3f8d34efddf2ee39f6b9204..2ec718ef2f5794c67bdfed8fd915033d472f21e5
You are receiving
I brought this change up for discussion on the Fedora devel list, and I've made
a couple of changes based on feedback provided there:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/EZFX5ARQWOXBUXID4HH74ETD2QBF2DPB/
--
Reply to this email directly or view it
@gordonmessmer pushed 2 commits.
441504ccb92ddfd4efaa7f07ee73d442fed5da1c Only generate versions when soname is
a symlink to a distinct filename.
e8c984425366463271cb25582804eb4807b5e6bc Use a more accurate name than
"libtool".
--
View it on GitHub:
> At this point I'd be mostly interested in feedback from other distro folks
Are you subscribed to the Fedora devel list?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1438895451
You are receiving this because you are
> I'm pretty sure this breaks the ability to swap between JACK and
> PipeWire-JACK because the soname versioning construct is frozen in
> PipeWire-JACK but regular JACK still gets version bumps.
It looks like it's the other way around, so in this case it's unlikely to be a
problem because
Checking in:
Is there anything I can do to help keep this moving forward? Would it be
useful to solicit feedback from a downstream group (e.g. fedora devel@) on
whether this is a usable appoach?
--
Reply to this email directly or view it on GitHub:
(Sorry for the lack of updates for a bit. I've been trying to wrap up a busy
quarter at work.)
I brought this topic up on the [opensuse factory
list](https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/3VB6U6B7RCJL2CDL3X6GNRPQGNO4D6E2/)
where Michal Suchánek brought up
I get that, and I want to find a way forward that continues to support
compatible library implementations.
Debian's approach is nice in that it allows library packages to indicate an ABI
version that compatible library implementations should also be able to provide,
maintaining their
@gordonmessmer commented on this pull request.
> +/*
+ * Rather than re-implement path searching for shared objects, use
+ * dlmopen(). This will still perform initialization and finalization
+ * functions, which isn't necessarily safe, so do that in a separate
+ * process.
+ */
+static char
@gordonmessmer commented on this pull request.
> +/*
+ * Rather than re-implement path searching for shared objects, use
+ * dlmopen(). This will still perform initialization and finalization
+ * functions, which isn't necessarily safe, so do that in a separate
+ * process.
+ */
+static char
@gordonmessmer commented on this pull request.
> + * a copy of the version number.
+ */
+static char *getLibtoolVer(const char *filename)
+{
+const char *so;
+char dest[PATH_MAX];
+int destsize = 0;
+int found_digit = 0, found_dot = 0;
+
+destsize = readlink(filename, dest,
> Also check that I/O errors (`EIO`, `ENOMEM`, `ENOSPC`, `EACCES`, `EPERM`,
> etc) result in a non-zero exit code.
*nod*
I'd asked in a code comment because I wasn't sure of the team's preferences, so
I'll ask it here to be really explicit: Should errors encountered during
fallback version
@gordonmessmer pushed 7 commits.
47db768e45187515dff5561dc5f209661d77b52b Enhance requires with version
information from the build root.
87aa2cbee9537bd6d5bad4fb0f713564a0e40706 Provide macros that can be used to
enable fallback version dependencies.
69c4c345772cfd0228562cc224296ea1cd409213
@gordonmessmer pushed 1 commit.
fccc4383940987f77c78ff4ade5cd692a2c4cbf3 Fallback requirements depend on GNU
extensions.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/957efd320451c2f33cfd704e92b13328683f64e6..fccc4383940987f77c78ff4ade5cd692a2c4cbf3
You
@gordonmessmer pushed 2 commits.
79e769bdf848ede042a055f9513cd56cb7226869 Exit on system failures.
cb8190e9b9f2795fac0e47a916ad2e1d7c7b3a8c Add basic documentation.
--
View it on GitHub:
Copying the commit message for the tests:
These tests are not compatible with fakechroot, for two reasons.
While fakechroot supports dlmopen(), it will convert relative paths
to absolute paths, which prevents library path searching. The test
could be run from the data directory
@gordonmessmer pushed 1 commit.
8894e4873ec8ab5795aa0ec53a99d8310eff93ce Add tests for the elf dependency
generator fallback version feature.
--
View it on GitHub:
@gordonmessmer pushed 1 commit.
5269fa3d535b9aff3c24509dac97c26bd8364154 Provide macros that can be used to
enable fallback version dependencies.
--
View it on GitHub:
The last commit includes macros that can be used to enable the fallback
dependency versions, which are off by default to provide a phased rollout of
the feature.
--
Reply to this email directly or view it on GitHub:
@gordonmessmer commented on this pull request.
> + version = getLibtoolVer(linkmap->l_name);
+ }
+ if (version)
+ (void) write(pipefd[1], version, strlen(version));
+ close(pipefd[1]);
+ free(version);
+ dlclose(dl_handle);
+ _exit(0);
+
@gordonmessmer commented on this pull request.
> +destsize = readlink(filename, dest, PATH_MAX);
+if (destsize > 0) {
+ dest[destsize] = 0;
+ filename = dest;
+}
+/*
+ * Start from the end of the string. Verify that it ends with
+ * numbers and dots,
Any advice or direction for adding tests? I see libhello.so and helloexe in
the testing data... libhello.so could be moved to libhello.so.0.0.1 and
replaced with a symlink, after which elfdeps should provide versioned
dependency information for those objects. Tests would need to be
@gordonmessmer pushed 1 commit.
930c6e99071a0d1121604aa2c5434b09c7d96e9d Exit on system failures.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/fccc4383940987f77c78ff4ade5cd692a2c4cbf3..930c6e99071a0d1121604aa2c5434b09c7d96e9d
You are receiving this
@gordonmessmer pushed 1 commit.
d0c8fc93976325c931d0a98d1c4ff73581dae8bd Provide an option to use libtool
version in elfdeps.c
--
View it on GitHub:
@gordonmessmer pushed 2 commits.
a01b715f68d025387ea394fa367730e30b9629a2 Enhance requires with version
information from the build root.
41da0a2924d11b23a3f8d34efddf2ee39f6b9204 Resolve symlinks when gathering
libtool version.
--
View it on GitHub:
@gordonmessmer pushed 1 commit.
f76936be945f1ef290a92507cb4f322bf719b8ce Provide an option to use libtool
version in elfdeps.c
--
View it on GitHub:
I've started work on elfdeps.c... It doesn't resolve symlinks to real paths, so
it doesn't get the version number we're actually after yet, and it segfaults if
it calls dlmopen() on libgobject, so that might not be a viable approach to
resolving a dependency to a path. But if anyone wants to
@gordonmessmer pushed 1 commit.
398827f176a1482fbde837b1b997395d024ff37a Resolve symlinks when gathering
libtool version.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372/files/d0c8fc93976325c931d0a98d1c4ff73581dae8bd..398827f176a1482fbde837b1b997395d024ff37a
You
> there's no requirement to run elfdeps through chroot
OK. I just wanted to be clear that those tests weren't run in chroot for a
reason.
> add a corresponding AT_SKIP_IF() in the tests
Thanks. Tests are conditional now with coverage of both GNU and non-GNU builds.
--
Reply to this email
Does anyone have any opinions on whether the version needs to be massaged in
any way? Libtool's version system is ... kinda weird. In most cases, we
probably only really care about the leading number, and using the second is
more restrictive than strictly necessary. I'm OK with that, but I
Is everyone happy with the naming of things? Especially the macro and the
command line option?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1426130025
You are receiving this because you are subscribed to this
@gordonmessmer pushed 1 commit.
159dd2d9ddef13c1b7a55b1007007619a62739eb Add tests for the elf dependency
generator fallback version feature.
--
View it on GitHub:
I'd been meaning to come back to this quite a while ago, but I got sick and
that put me out for a *long* time.
I still think that *something* should be done with the ELF dep generator, but
more discussion would be helpful.
I mentioned that Debian's approach came up in discussions. On one
> Oh. Yes, I'm subscribed there, so by "other distro folks" I meant non-Fedora
> people
@pmatilai , is there anything I can do to move that conversation forward?
I've written a description of these changes in the form of a design proposal:
@gordonmessmer pushed 1 commit.
9cb6fc8272970b074e77076369f88a5cacb5c13a Rather than read the version for an
ELF shared object directly
--
View it on GitHub:
I've added a commit to illustrate a slightly different approach. Code quality
and error handling need more work, and there are no new tests, but I'd like to
ignore that for the moment and discuss only whether this approach is worth
developing further.
This change adds another file to packages
1 - 100 of 108 matches
Mail list logo
