Overview
Request History
rmax created request
- Remove the SQLite extension and package it as a subpackage of
sqlite3 to have only a single copy and keep it more up to date
(bsc#1195773).
- Clean up the lib dependencies in tclConfig.sh and tcl.pc.
(bsc#1179615, bsc#1181840).
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
dimstar accepted review
dimstar_suse set openSUSE:Factory:Staging:C as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:C"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:C"
dimstar declined review
nothing provides sqlite3-tcl needed by tcl
and tcl being ring0 / distro bootstrap requiring anything from a package far down the list sounds like a really, REALLY bad idea; this would essentially pull sqlite3 into the distro bootstrap cycle (currently it can't even build sqlite, as tcl was already built, requiring a package that does not yet exist, …)
dimstar declined request
nothing provides sqlite3-tcl needed by tcl
and tcl being ring0 / distro bootstrap requiring anything from a package far down the list sounds like a really, REALLY bad idea; this would essentially pull sqlite3 into the distro bootstrap cycle (currently it can't even build sqlite, as tcl was already built, requiring a package that does not yet exist, …)
dimstar_suse reopened request
dimstar_suse accepted review
Staging Project openSUSE:Factory:Staging:C got accepted.
dimstar_suse approved review
Staging Project openSUSE:Factory:Staging:C got accepted.
dimstar_suse accepted request
Staging Project openSUSE:Factory:Staging:C got accepted.
Quoting from the reject message:
See https://build.opensuse.org/request/show/965652
Please discuss this in bsc#1195773 where it was demanded that Tcl uses libsqlite from the system rather than its embedded copy.
BTW, can't we break that cycle by ignoring the dependency of tcl on sqlite3-tcl within OBS? For the use cases of Tcl within OBS the SQLite extension is most likely not needed. I just added the dependency so that users of the Tcl package always get the full set of extensions that come bundled with the core.
we CAN - but we really should not mess with deps in OBS
a 'requires; mean 'is needed to function properly' if it's not required and a dep can be broken, then the requires is wrong
What you might rather want apparently:
Requires: (sqlite3-tcl if sqlite3)- i.e when the user installs sqlite3 AND tcl, then sqlite3-tcl should be required. Then there is a reasonable expectation after all that the user will want to use sqlite3 (possibly from within tcl)In general I agree with that, and I am frequently criticising packages that do not follow it without a good reason.
But this particular case is a bit different. The SQLite binding for Tcl used to be a separate and optional package, but with Tcl version 8.6 upstream decided to bundle a set of extensions with the core, so that developers of Tcl applications can normally rely on them to be there. This is called the "batteries included" Tcl distribution and SQLite is one of these embedded packages. Back then I decided to follow this move and henceforth have "tcl" mean "The Tcl core and all bundled extensions". To keep this promise I had to add the dependency, now that we have to "outsource" one of the bundled packages to fulfill other policies.
Sounds like a perfect fit for Recommends
If I had thought that
Recommendswould be a good fit here, I would have used it. ;)I really want to keep the semantics of what comes with the
tclpackage unchanged by this move of functionality into a different package that was done for other reasons than modularisingtcl. And the only way to get that isRequires.Still not really happy about it - but in order to move forward, I'll add that Ignore.
a package claiming 'requires' and the maintainer in the same sentence claiming "can be ignored' is obviously a lie in the spec file (and I don't use tcl on my machine - so I care even less :P )
But the move from built-in to externally built to upkeep the promise somewhat makes sense (5%)
Thanks for now.
In the future I could imagine having a
tcl-corepackage that contains the bare minimum and atclpackage that contains the "batteries" andRequiresthe single one that it doesn't contain. Then the dependency cycle can be broken by buildrequiring onlytcl-coreby the packages in the bootstrap loop that probably don't need the batteries anyway, and bysqlite3. But I want to reserve such a big change until the next upgrade to 8.7 or even 9.0.sounds good as a mid-term plan
Sorry, crap from the past is no white-card for the future - let alone that a lot of those ignores are probably not even valid anymore
Will try to shorten that list to what makes sense nowadays
just by looking at things which are obvious: down to 231 (incl the new tcl ignore)
Can't be built - because tcl, part of the distro bootstrap, built first. and now sqlite3 can't even setup the buildroot to get going, as tcl is uninstallable.