Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3 July 2017 at 02:04, Stephen John Smoogen <smooge@xxxxxxxxx> wrote:
> On 1 July 2017 at 21:42, Nick Coghlan <ncoghlan@xxxxxxxxx> wrote:
>> On 1 July 2017 at 03:36, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
>>> On Fri, 2017-06-30 at 12:07 +1000, Nick Coghlan wrote:
>>>> Even if a 4.0 does happen, the magnitude of the change relative to the
>>>> preceding 3.x release is expected to be comparable to that between any
>>>> given 3.x and 3.x+1 release, so it wouldn't require the parallel stack
>>>> approach that has proven necessary to handle the core data model
>>>> changes that impacted the 2->3 transition.
>>>
>>> I thought it would be tolerably obvious that I didn't mean "literally
>>> the specific conceptual Python 4.0 that at one point was expected to
>>> exist after 3.9" or "any specific Python 4 release that happens".
>>> Clearly what I meant was "any future non-backwards-compatible major
>>> Python release". Maybe *right now* you don't expect there to be one,
>>> but I'm sure there was probably a point during Python 1's lifetime at
>>> which no-one expected there to be a backwards-incompatible Python 2,
>>> and a point during Python 2's lifetime at which no-one expected there
>>> to be a backwards-incompatible Python 3...
>>
>> No, as in the process of maintaining Python 2 & 3 in parallel for over
>> a decade, we've significantly improved our toolset for *not* painting
>> ourselves into similar corners in the future (and we're likely to
>> introduce even more technical capabilities along those lines over
>> time, such as Victor Stinner's proposal for a more flexible runtime
>> code transformation pipeline).
>>
>> Now, obviously, we can't *stop* redistributor communities like Fedora
>> from collectively declaring those process, policy, and technology
>> changes ineffective, and instead investing their time and energy in
>> planning for future disruptions that probably aren't going to happen.
>> However, we *can* provide the advice that we don't believe such
>> endeavours are going to represent a good use of that time and energy.
>>
>
> OK here is the problem with this whole conversation in a nutshell.
> Each side thinks the other one is bikeshedding and stopped listening
> to the other.

Thanks for the excellent summary of the situation Stephen. I'm not
going to respond point by point, but instead use your post as a
launching point for an arguably radical notion: we could explicitly
explore supporting "late binding" of RPM dependency declarations in
order to better support the folks that need old pieces of software to
"just work" when built or run on a newer system, but are also prepared
to keep all the pieces if they end up breaking that system in the
process.

> Here is the distributor problem in a nutshell. You will have people
> come in who are not part of the the upstream community who just want
> to get some old code they have working. They follow some old written
> down instructions and find that boom instead of a working thing they
> now have a broken pile of bolts with no idea why.

Jason's offer to go backfill EPEL with "python2-*" metapackages
prompted a question I hadn't really thought about before: what if we
had a way to effectively generate additional virtual-provides at
*installation time*, rather than all such declarations having to be
baked directly into the RPMs at build time?

That is, suppose we *never* added back build-time virtual provides for
the "python-*" names, and instead added a new config file inside a new
config directory "/etc/yum/aliases.d/" that said "If 'python-(.*)'
isn't found, check for 'python3-\1' instead". DNF would then
automatically convert any given name translation rules into the
appropriate "OR" clauses in the rich dependency system.

The net effect of this would be that, *by default*, unqualified
"python-*" references would resolve to python3-*, just as they would
if we updated the %python_provides macro.

However, the big difference is that an end user could, if they wanted
to, adjust their build environment (e.g. in a mock chroot) such that
unqualified "python-*" references resolved to "python2-*" instead.
That's something they can't readily do when the aliases are defined in
the built RPMs - instead, you have to rebuild the world just to switch
some aliases around.

Such a system may even have more potential uses than just assisting
with the Python 3 migration. For example:

- install-time name translations between different distros (Py2 vs Py3
being just one example)
- working around missing virtual provides in pre-built RPMs (e.g.
missing "distXY(upstream-name)" metadata)
- potentially making it easier to derive parallel-installable SCLs
from mutually-exclusive modules

So while I freely admit the idea is entirely speculative handwaving at
this point, it seems to me like an approach that could even be
integrated into the xdg-alternatives system (such that runtime
switching can have complementary changes to install-time aliases),
whereas anything we do purely at build-time is inherently inflexible
from an end user's perspective.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan@xxxxxxxxx   |   Brisbane, Australia
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux