Re: Goodbye nvr.rsplit('-', 2), hello modularity
by Michal Novotny
On Tue, Mar 20, 2018 at 3:31 PM, Jan Kaluza <jkaluza(a)redhat.com> wrote:
> On Tue, Mar 20, 2018 at 10:06 AM, Michal Novotny <clime(a)redhat.com> wrote:
>>
>> The question here is why don't we actually implement the modularity
>> the simple way.
>>
>> Let's suppose I would like to make nodejs-8 available in EPEL7.
>>
>> The most effortless way would be to create subdirectory called 8 at
>> src.fedoraproject.org/rpms/nodejs
>> with the updated spec file and sources for the bumped major version of
>> the nodejs package.
>
>
> What if your module contains packages coming from multiple SRPMs and they
> depend on each other?
Well, my module wouldn't be coming from multiple SRPMs because my
module is just a normal package.
The problem with modularity is that the name does not really fit what
it does, which is kind of important because wrong names make
implementation much harder as you cannot rely on your common
sense.
When I think of a module, rpm ultimately comes to mind. That's kind of
a unit that makes up an operating system.
I highly doubt modularity can change it unless it invents its own package
format. So I think it would be good to call it differently even in the tooling.
So let's try to figure out a better name for modulemd.
Basically, the final product of modulemd is a repo with some built rpm
packages in it (if I saw the latest development correctly, we were squashing
multiple of those repos into a single one but we wouldn't need to do that).
For users, a repo represents something like a stream of content. So
streammd would be already a better name.
But even a better name would be coprmd because you can think about
the current "modulemd" as a copr (community project) being formally
described in a file. Product of a copr project is also a repo so it fits.
Stream name here:
https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml...
is basically a project name.
The content specified here:
https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml...
are basically definitions of SCM packages.
And then there are some fields like:
version: 20160927144203
context: c0ffee43
which doesn't really belong there imho but instead belong to the final
built repository (= copr snapshot) as a part of repodata (if anywhere).
So I think it would be good to keep talking about packages when
we talk about modules.
clime
>
> Jan Kaluza
>
>>
>>
>> For fedpkg to be able to upload and download sources for that
>> subdirectory (submodule), the attached
>> single-line patch is needed in python-rpkg. There are a few more
>> changes needed to make srpm
>> importing work but it should be basically almost done as well.
>>
>> Koji then just needs to learn how to build DistGit repositories
>> containing submodules where
>> submodule is any subdirectory containing a spec file. When Koji
>> discovers all the submodules
>> in a repository, it can start an srpm and a consequent rpm build for
>> each of them.
>>
>> It is a very similar approach to what find_packages from python
>> setuptools implements. It
>> recognizes subpackages based on the presence of __init__.py file. The
>> only difference here
>> is that we will be recognizing subpackages (=submodules) by the
>> presence of *.spec file.
>>
>> Everything else should be pretty much the same otherwise. Koji builds
>> nodejs-6 and nodejs-8 rpms
>> both with el7 disttag and both of these can go through the Bodhi
>> update process separately.
>>
>> Of course, the question is if you can actually build and run nodejs-8
>> in EL7 successfully but
>> I think that will always be a problem no matter what the implementation
>> is.
>>
>> clime
>>
>> On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza <jkaluza(a)redhat.com> wrote:
>> >
>> >
>> > On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson
>> > <adamwill(a)fedoraproject.org> wrote:
>> >>
>> >> On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote:
>> >> > On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote:
>> >> > > So you think having to send a request to a web service instead of
>> >> > > just
>> >> > > parsing a string locally with one line of code is a good trade-off
>> >> > > for
>> >> > > allowing dashes?
>> >> >
>> >> > This has been mentioned several times in this thread and I think
>> >> > there's
>> >> > a misunderstanding around this.
>> >> >
>> >> > So: When your tool/whatever works with modules it will have to have
>> >> > module metadata available in some form.
>> >>
>> >> What if I don't want to work with modules at all, just with information
>> >> about modules?
>> >>
>> >> What if I just want to write a tool that parses fedmsgs about module
>> >> builds in Koji and does something that depends on module names, streams
>> >> and versions? (e.g. some sort of changelog thing)
>> >
>> >
>> > Your tool can use good old buildsys.build.state.change fedmsg with the
>> > well
>> > known name/version/release fields like this:
>> >
>> >
>> > https://apps.stg.fedoraproject.org/datagrepper/raw?topic=org.fedoraprojec...
>> >
>> > That's staging, because it's easier for me to find the module builds
>> > there
>> > :).
>> >
>> > Unfortunatelly, Koji does not add "type" field there, so you cannot find
>> > out
>> > if that's module or not. But in case your tool is doing general
>> > changelog
>> > per Koji build, it will work quite well with modules without you even
>> > noticing you are working with modules.
>> >
>> > In case of tools, you can even query koji using its api and pass the
>> > name/version/release there, instead of NVR.
>> >
>> > If you query Koji for the module build, you will actually find whole
>> > module
>> > metadata in "extra" part of the build.
>> >
>> > In case you are OK with using MBS fedmsgs, you can use the fedmsgs Nils
>> > already sent in this thread.
>> >
>> > Regards,
>> > Jan Kaluza
>> >
>> >> --
>> >> Adam Williamson
>> >> Fedora QA Community Monkey
>> >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>> >> http://www.happyassassin.net
>> >> _______________________________________________
>> >> devel mailing list -- devel(a)lists.fedoraproject.org
>> >> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> >
>> >
>> >
>> > _______________________________________________
>> > devel mailing list -- devel(a)lists.fedoraproject.org
>> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> >
>>
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>>
>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
6 years, 3 months
F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Make DNF5 the new default packaging tool. The change will replace DNF,
LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library.
It is a second step after
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf.
== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmracek(a)redhat.com
== Detailed Description ==
The new DNF5 will provide a significant improvement in user
experiences and performance. The replacement is the second step in
upgrade of Fedora Software Management stack. Without the change there
will be multiple software management tool (DNF5, old Microdnf,
PackageKit, and DNF) based on different libraries (libdnf, libdnf5),
providing a different behavior, and not sharing a history. We can also
expect that DNF will have only limited support from upstream. The DNF5
development was announced on
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Fedora-Devel] list in 2020.
=== New DNF5 Features ===
* Fully featured package manager without requirement of Python
** Smaller system
** Faster
** Replace DNF and Microdnf
* Unified behavior of in the software management stack
** New Libdnf5 plugins (C++, Python) will be applicable to DNF5, Dnf5Daemon
*** DNF4 plugins were not applicable for PackageKit and Microdnf (e.g.
versionlock, subscription-manager), therefore PackageKit behaves
differently in comparison to DNF
** Shared configurations
*** In DNF4 not all configuration is honored by PackageKit and Microdnf
** DNF/YUM was developed for decades with impact of multiple styles
and naming conventions (options, configuration, options, commands)
* New Daemon
** The new daemon can provide an alternative to PackageKit for RPMs
(only one backend of PackageKit) if it will be integrated into Desktop
** Support of Modularity and Comps group
* Performance improvement
** Loading of repositories
** Advisory operations
** RPM queries
*** Name filters with a case-insensitive search (the `repoquery` command)
** Smart sharing of metadata between dnf5 and daemon
*** Reduce disk and downloads requirements
*** Currently, DNF, Microdnf, and PackageKit use their own cache
*** Optional, may be not available for Fedora 39
* Decrease of a maintenance cost in the long term
** Shared plugins
** Removal of functional duplicates
* Fully integrated Modularity in LIBDNF5 workflows
** The Modularity is supported in DNF and LIBDNF but it is not fully
integrated. Integration was not possible due to limitation of
compatibility with other tools (PackageKit)
** Fully integrated Modularity required changes in the library workflow
=== Major codebase improvements ===
*Reports in structure
** DNF reports a lot of important information only in logs
* Removal of duplicated implementation
** LIBDNF evolved from LIBHIF (PackageKit library) and HAWKEY (DNF
library). The integration was never finished, therefore LIBDNF still
contains duplicated functionality.
** decrease of the code maintenance cost in future
* Unify Python bindings
** Formal Libdnf provides two types of Python bindings
*** CPython (hawkey)
*** SWIG (libdnf)
** Maintaining and communication between both bindings requires a lot
of resources
** Binding unification was not possible without breaking API compatibility
* SWIG bindings
** With SWIG we can generate additional bindings without spending huge resources
** Code in particular languages will be very similar to each other
* Separation of system state from history DB and `/etc/dnf/module.d`
** In dnf-4 the list of userinstalled packages and list of installed
groups along with the lists of packages installed from them is
computed as an aggregation of transaction history. In dnf5 it will be
stored separately, having multiple benefits, among them that the
history database will serve for informational purposes only and will
not define the state of the system (it gets corrupted occasionally
etc.).
** Data stored in `/etc/dnf/module.d` were not supposed to be user
modifiable and their format is not sufficient (missing information
about installed packages with installed profiles)
*** Content of `/etc/dnf/module.d` will be moved into the System State
== Feedback ==
== Benefit to Fedora ==
== Scope ==
* Proposal owners:
DNF5 is still in the development and some of the features or options
are not yet available. We still have to finish the implementation of
Modularity, storing internal data related to History and System State,
and also documentation and man pages. DNF5 can be tested from
repository with upstream nightly builds -
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/.
The project's github repository is here -
https://github.com/rpm-software-management/dnf5/
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`,
and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`,
`python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`.
=== Compatibility ===
The new DNF5 will provide a symlink to `/usr/bin/dnf` therefore users
will see the replacement as an upgrade of DNF with limited but
documented syntax changes. The DNF5 will provide some compatible
aliases of commands and options to improve adoption of the DNF5.
== How To Test ==
Install `dnf5` package from
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/
== User Experience ==
* Improved progress bars
* Improved transaction table
* Transaction progress reports including scriptlets reports
* Support of local rpm for transaction operation
* Great bash completion (better then DNF has)
* New commands and options that are only available with `DNF`
== Dependencies ==
There is a long list of dependent packages
=== dnf ===
auter
calamares
copr-builder
cpanspec
dnf-plugin-diff
dnfdragora
etckeeper-dnf
fedora-review
fedora-upgrade
kiwi-systemdeps-core
libdnf-plugin-subscription-manager
lpf
mock
osbuild
perl-CPAN-Plugin-Sysdeps
policycoreutils-devel
rbm
subscription-manager
supermin
system-config-language
=== python3-dnf ===
anaconda-core
dnf-plugin-ovl
dnfdaemon
fedora-easy-karma
fedora-review
lorax
mock-core-configs
module-build-service
modulemd-tools
needrestart
pungi
python3-bodhi-client
python3-dnf-plugin-cow
python3-dnf-plugin-flunk_dependent_remove
python3-imgcreate
python3-libreport
retrace-server
system-config-language
=== libdnf ===
PackageKit
copr-builder
gnome-software-rpm-ostree
libdnf-plugin-subscription-manager
libdnf-plugin-swidtags
libdnf-plugin-txnupd
=== python3-hawkey ===
mock-core-configs
modulemd-tools
python3-rpmdeplint
retrace-server
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
* Contingency deadline:
* Blocks release?
== Documentation ==
none
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 9 months
Re: Goal: Increased Modularity?
by Les Mikesell
Richi Plana wrote:
>> I'm not sure I understand. Shouldn't you be able to use any version of
>> a jvm, packaged or not, without specific dependencies, just like you
>> could use different media players to play the same file? Or even run
>> more than one of them at once?
>
> Sorry, that was a bit vague. I just meant that a piece of java bytecode
> is usually designed to be executed in one way (either as a java
> application, web application, applet, etc.) or 2 or 3 at the most. Media
> files can be used in so many ways, not just playing them (editing,
> converting, analysis, etc.) Anyway, the point is that it's just not the
> best example to illustrate your point, and not that it doesn't.
OK, the likely scenarios are that you have different apps that only work
with one JVM each, and even with one app you always want to be able to
test it under different JVM verions (including the next update) before
thinking about changing the system default.
>> Yes, thanks, and sorry - I missed the one actual answer in the first
>> link, but I was confused by the comment somewhere about parts going to
>> private and export directories that didn't seem to be under the same top
>> level. Is everything expected to be under JAVA_HOME actually still in
>> one place?
>
> I honestly don't know. 1) So far, it's worked for me, 2) looking at the
> contents of the JRE (java-1.5.0-(sun|ibm)), it seems that apart from a
> couple of JAR files located in jvm-exports/ and jvm-private/, all the
> files are in (quotes) "$JAVA_HOME". Anybody read the pertinent JSR on
> JAVA_HOME directory layouts care to comment?
The answer I have really been looking for is that the concept of
JAVA_HOME reliably still exists, and how to use it in spite of the
efforts to hide where it lives in the alternatives universe.
--
Les Mikesell
lesmikesell(a)gmail.com
16 years, 9 months
Re: Aggressive updating (Python 3.9): Are we trying to hard?
by Stephen John Smoogen
On Wed, 20 May 2020 at 15:39, Miroslav Suchý <msuchy(a)redhat.com> wrote:
> Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a):
> > Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8.
> But instead of asking ourselves, "should we push
> > in the VERY latest Python and hope it's ok?", we just patch the build
> system to accept it anyway and hope for the best.
> >
> > Qt (et all) is a pretty organized upstream, so when asked about Python
> 3.8 support in 5.13.x, they said, "Nope. Wait for
> > 5.14.x."
> >
>
> BTW this is scholar example of use-case for Modularity.
>
>
Maybe if each python module is made parallel installable AND each app which
uses python is tied to using that exact version of python versus python3.
Otherwise you could end up with QT apps needing python3.6, XYZ (let us say
TeX) apps needing python3.8 and dnf needing python3.9 and ONLY ONE OF THESE
CAN BE INSTALLED. And since dnf needs to be there.. I guess you would have
no QT or whatever.
If each of them have been patched to be parallel installable and the apps
have been patched to call python3.8 versus python3.. the only thing
modularity is helping is with giving a list of builds orders to make ti
work correctly. It also adds to each of those groups the maintenance of
those python modules because the python team has just enough people to
maintain 1 module. Not 2, not 3, not one for every old version of python3.
> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
--
Stephen J Smoogen.
4 years, 1 month
Re: Fedora Modularity: What's the Problem?
by Zbigniew Jędrzejewski-Szmek
On Mon, Oct 28, 2019 at 03:56:11PM -0400, Stephen John Smoogen wrote:
> I think the issue is that neither of you are defining what expected
> lifespans of stability or what stability is. After that you can
> disagree whether it is important or not to what you want to do... but
> until then you are both talking past each other.
You are right. My statement was vague enough to be useless.
Let me try again:
I don't think Fedora is a good base to build or install packages that
will not change for a long time, where long time is anything longer
than one or two Fedora releases.
And I do mean *packages*, not software in general. The ability to build
software depends on the underlying kernel and glibc and compilers and
libraries, and those remain broadly backwards compatible. But we change
the way things are packaged and configured: new compilation flags, new
security features, latest glibc and gcc, latest kernel, latest
systemd, latest python, new CI checks, appdata, new version of cgroups
or firewall implementation, etc. Those changes requires constant
tweaks to packaging, but provide packages that improve over time.
We are trying to add automation to packaging of python and rust and
other upstream projects.
This all means that even if a package from two years ago still builds
or installs in Fedora, we most likely do not *want* it, because we
require more from our packages, but also because have better ways to
build packages.
Stephen said:
> Yes, RHEL and CentOS have a particular business model that rides on
> "nothing changes". Modularity offers us the chance to take some of our
> more radical changes and phase them in, rather than push every user
> onto them at an upgrade boundary. The assertion that users of Fedora
> wouldn't be welcoming to "my apps are more stable but I still get the
> latest kernel/platform stuff" is, in my opinion, incorrect.
This is exactly the circle which I think we can't square.
There is no "kernel/platform stuff" that we can keep updating while
providing a uniform interface to higher layers or anything like that.
Let me use an example: F32 will switch to python3.8. Many packages
required fixes to work with python3.8. Python maintainers (and many
other Fedora developers) worked with upstream projects, and many
upstream projects made releases with patches either written by us
or for us. This often coincided with dropping python2 support.
At the same time, sphinx and pytest released new major versions.
This means that Fedora pushed the whole ecosystem forward, but
keeping packaging unchanged in F29 (python2 is still king), and F32
(python3.8 is required) is very hard. And anything which is closely
dependent on python will require some small changes.
For me, stability of the core to allow the same packages to be reused
across versions is an anti-goal and something that shouldn't be promised.
This might happen, but should not be constrained by what changes we can
make. Instead, I want the distro to keep running forward as a whole,
with the ability to coordinate changes to multiple projects and packages
when the need arises and flexibility to change packaging standards and
mechanisms and require rebuilds.
The problem is completely different in RHEL/Centos because the cadence
is much longer. I see how important it is for users there to gain
access to alternative versions of packages. But in Fedora, such
packages are always at most a few months away. So yeah, I do hope Fedora
can be more stable (in the sense of a bug-free and smoothly upgrading system),
but not stable (in the sense of unchanging).
Zbyszek
4 years, 8 months
Re: Modularity and the system-upgrade path
by Zbigniew Jędrzejewski-Szmek
On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
> If I were to start from scratch on this, I would look at the simplest
> solution I would want from Boltron. I want to make it so a package team can
> make a set of packages in a repository and work out how I can interact with
> other repositories. I also want to easily build that package set in ways to
> work on different versions of an operating system.
The question is whether this team wants to do the "heavy lifting"
(which might or might not actually be very heavy), of integrating with
the rest of the distro. If they don't, then Copr is the answer: it
provides all the answers, including automatic rebuilds.
If they do, and they invest in following the packaging guidelines and
and the release cycles and whatever we say makes the package suitable
for users and other packagers to build on, they get to put the package
in the distro.
> 1. They have a lot of packages they need to tie together
> 2. They need to build those packages for multiple deliverable operating
> environments
> 3. They need to interact with other groups of packages in a way which that
> their group can 'know' if there is a chance of coworking.
> 4. Many are tied to systems which have fast, hard update cycles which do
> not work with even a 'fast' OS like Fedora.
>
> Users are wanting
> 1. A system which can tie these different speed things together.
> 2. That system to be updated or is clear on why it can't and what needs to
> be done.
This is all already satisfied by rpms (even from Copr).
In particular, for point 3., there can be no magic: we can *express*
relationships between packages with Provides and Requires, but to
*know* what should be expressed, we need packager input _and_ ideally
lots of QA and testing. No new repo format and metadata language fundamentally
changes this.
Zbyszek
4 years, 8 months
Re: How attached are we to branch ACLs? -- Should we kill pkgdb?
by Kevin Kofler
Pierre-Yves Chibon wrote:
> Of course, EPEL vs Fedora comes to mind here, but I wonder: if the EPEL
> maintainer has also commit on the Fedora branches, is it really that much
> of a big deal? And vice-versa?
Well, I don't want to get the EPEL bugs assigned to me.
> PS2: I am also considering this question having in mind the change in
> branching model the modularity work will bring (ie: branch no longer tied
> to a Fedora version but rather to upstream's version)
As I already mentioned in person when this came up in a DevConf talk, I
think that this is a plan that will likely break a lot of things, especially
the expectations all our users rely on (that everything in Everything has a
consistent guaranteed life time), and that doing away with that expectation
is going to make Fedora a lot less useful for many of our users (including
myself and probably also other contributors). Guaranteeing a life time for
the modules included in specific deliverables (spins, "editions", etc.) does
not help, because in the real world, users install many add-on packages from
our repository, its size is one of the main strengths of Fedora.
In fact, this change may even make me look for another distribution, and I
cannot be the only one. I cannot possibly track for each of the hundreds of
packages (not counting texlive-* because they all come from the same SRPM,
otherwise I would write "thousands" rather than "hundreds") that I have
installed when I have to manually switch to a later major version because
the maintainer arbitrarily decided to discontinue the version that I am
using. Nor do I want major versions automatically dragged in without
warning. The Fedora releases are a great point to put in major changes like
that.
All in all, I think modularity causes more problems than it solves. There
are major practical advantages of having global release branches with a
global lifetime.
Kevin Kofler
7 years, 3 months
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
by Neal Gompa
On Fri, Oct 18, 2019 at 11:43 AM Randy Barlow
<bowlofeggs(a)fedoraproject.org> wrote:
>
> On Fri, 2019-10-18 at 11:21 -0400, Robbie Harwood wrote:
> > Obviously we
> > can't use their code wholesale without migrating to APT, but as you
> > say,
> > the goal is to derive inspiration.
>
> But yeah as you say here, my original point was more that we could
> learn from what others did and integrate similar concepts into RPM/dnf,
> especially since what they did was simpler, and as a result of that
> simplicity didn't struggle to gain adoption. Those concepts were also
> easier to write the code to make them happen. For example, adding a
> slot field to the RPM would be pretty easy and I think is obvious that
> we wouldn't need to create build services like Ursa Major to make that
> work. We would need a change to Koji and dnf to consider the slot as
> part of a package's uniqueness, but I think that's a small change in
> comparison. It's easier to create and easier to use, which I see as a
> win-win.
>
> Thanks for mentioning the Debian solution. I wasn't familiar with that
> one. This means we have even more solutions to study for inspiration.
>
> Too fast, too slow is a solved problem and there are existing solutions
> to learn from or even adapt. We don't need to make our own.
RPM + DNF actually already supports Debian's solution.
Philosophically, RH/Fedora systems don't typically use alternatives as
aggressively as Mageia, SUSE, or Debian systems. We do actually
generate virtual names and use them, and we can use them to satisfy
things like this. We already do this with Rust by having parallel
installable stuff with common names that work with ranged
dependencies.
There are other things we could do along these lines, too...
--
真実はいつも一つ！/ Always, there's only one truth!
4 years, 8 months
Re: Modularity and all the things
by Kevin Kofler
Przemek Klosowski via devel wrote:
> On 11/5/19 7:18 PM, Kevin Kofler wrote:
>> "name mangling": Why is this a problem? First of all, it is not mangling,
>> it is suffixing. The original name is retained unchanged and nothing is
>> prepended to it, only appended. And, e.g., Qt 3, 4, and 5 are all
>> different packages, so why should they have the same package name?
>
> For this specific point, it is nice to have a generic name (qt, or
> python, or sqlite, or whatever) that describes the current, default
> version. Most of my databases don't care about sqlite2, so typing
> sqlite3 feels like some sort of cargo cult ceremony. I feel the same is
> true of most software---the ecosystem evolves and tends to be compatible
> with latest version of their dependencies. The suffixed names should be
> used only if the underlying system really cares about that specific
> suffix.
>
> This does not contradict any of what you said---just that I end up
> creating aliases (sqlite -> sqlite3, python -> python3, etc) that in my
> opinion should be provided by the distribution. It's not a big deal, in
> any case: maybe the biggest practical effect of all this is that default
> names promote keeping up with the ongoing development----it's harder to
> write Python2-dependent code if you have to explicitly invoke
> #!/bin/python2, as sort of a version-shaming.
You are talking about binary names there, whereas I was talking about
package names. Though of course, to get parallel-installable packages, any
included binaries typically have to be suffixed as well.
The drawback of renaming the binaries is that it breaks existing user
scripts (and also other packages). For Python, the Python SIG went through
with it anyway (unsuffixed Python is now Python 3, assuming you have python-
unversioned-command installed at all to begin with), also because they seem
to consider breaking everything Python 2 by default to be a feature. The
SQLite maintainer(s) decided differently.
Kevin Kofler
4 years, 7 months
