Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation
On 12/18/19 6:28 PM, Michael Orlitzky wrote: > > This *does* happen if you mask virtual/emacs. It *could* happen if you > delete it. > I tested this out. Portage seems OK with the missing dependency, but for the overall plan to work, you have to wait a long time before deleting virtual/emacs; otherwise the upgrade path is broken. With virtual/emacs-26 installed and "old" copies of the elisp ebuilds installed, you get unsatisfied dependencies switching from emacs-vcs to a live slot of emacs. Everyone in that situation must update to virtual/emacs-26-r1, which they can't do after you delete it. And of course you can't mask virtual/emacs in the meantime, because that does kill the PM. New revisions would still be the sane solution, now and in the future, because they don't require investigative journalism to uncover exactly what might go wrong when we bend the rules /this time/. They also don't impose a cutoff date after which upgrading users are screwed. You just automate the revbumps, commit them all at once, and make a pull request against CI to verify that nothing is too borked.
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On 12/19/19 12:37 PM, Michał Górny wrote: > > Just because someone did something crappy, it doesn't mean it was > considered 'good enough'. It was just a cheap hack that someone once > did just to get it over with and stop caring. Not a good solution we > should keep copying. > These should all be USE=bundled-foo, and off by default at the very least.
[gentoo-dev] [EAPI 8 RFC] Install-time dependencies
Hello,
Here's another potential EAPI 8 feature I'd like to discuss. Please
note that this is about *new dependency type*, so please don't hijack it
into the big 'let's steal Exherbo syntax' debate.
Bug: https://bugs.gentoo.org/660306
The problem
===
Right now we don't really have a clean way of specifying dependencies
that are used during pkg_*inst (and pkg_*rm?) phases. So far RDEPEND
was used as a 'close enough' alternative (except for a few developers
who rejected it as 'invalid' and used DEPEND which is even more wrong).
However, this is no longer sufficient with EAPI 7 cross support.
By design, pkg_*inst phases are run in build host's environment when
cross is used (because obviously you can't run target host executables).
Therefore, the relevant dependencies need to be installed into CBUILD
root, while RDEPEND is installed into CHOST root.
The proposed solution
=
The proposal is to add a new dependency type (codename: IDEPEND) which
indicates dependencies used for pkg_*inst (and pkg_*rm?) phases. Those
dependencies would be installed into CBUILD root (like BDEPEND), and
therefore would be runnable from build host. Similarly to RDEPEND, they
would be installed for binary package installs but not for pure binpkg
builds (without install).
Example:
inherit xdg-utils
IDEPEND="dev-util/desktop-file-utils"
pkg_postinst() {
xdg_desktop_database_update
}
WDYT?
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On Thu, 2019-12-19 at 19:43 +0100, Sebastian Pipping wrote: > On 19.12.19 18:37, Michał Górny wrote: > > We have a better alternative that lets us limit the impact on the users. > > Why not use it? > > Which one? The CMake bootstrap copy? The adding to stage3 one? > Bootstrap version. It doesn't have to be a strict copy. The whole point is that even if it's buggy, unmaintained, vulnerable, it's impact is going to be minimal. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On 19.12.19 18:37, Michał Górny wrote: > We have a better alternative that lets us limit the impact on the users. > Why not use it? Which one? The CMake bootstrap copy? The adding to stage3 one?
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On Thu, 2019-12-19 at 18:28 +0100, Sebastian Pipping wrote: > Hey! > > > On 19.12.19 17:03, Michał Górny wrote: > > > B) Introduce USE flag "system-expat" to CMake similar to existing > > >flag "system-jsoncpp", have it off by default, keep reminding > > >CMake upstream to update their bundle > > > > > > [..] > > > > It violates the policy on bundled libraries. > > Same for the dev-util/cmake-bootstrap approach, right? > > > > What's worse, the awful > > USE flags solution means that most of the Gentoo devs end up using > > bundled libraries just because people are manually required to figure > > out what to do in order to disable them. > > I didn't say that it's perfect :) It's the same approach that we have > have with the system-jsoncpp USE flag already so that was considered > good enough at some point in the past. I guess we want the same for > Expat and jsoncpp? Which alternative do you see as better than a new > flag system-expat? > Just because someone did something crappy, it doesn't mean it was considered 'good enough'. It was just a cheap hack that someone once did just to get it over with and stop caring. Not a good solution we should keep copying. We have a better alternative that lets us limit the impact on the users. Why not use it? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Hey! On 19.12.19 17:03, Michał Górny wrote: >> B) Introduce USE flag "system-expat" to CMake similar to existing >>flag "system-jsoncpp", have it off by default, keep reminding >>CMake upstream to update their bundle >> >> [..] > > It violates the policy on bundled libraries. Same for the dev-util/cmake-bootstrap approach, right? > What's worse, the awful > USE flags solution means that most of the Gentoo devs end up using > bundled libraries just because people are manually required to figure > out what to do in order to disable them. I didn't say that it's perfect :) It's the same approach that we have have with the system-jsoncpp USE flag already so that was considered good enough at some point in the past. I guess we want the same for Expat and jsoncpp? Which alternative do you see as better than a new flag system-expat? Best Sebastian
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On Thu, 2019-12-19 at 15:39 +0100, Sebastian Pipping wrote: > Hey! > > > Thanks everyone for your thoughts so far! > > From what I heard, these two options seem realistic to me: > > A) Ask the KDE team for help with teaming up on a new package >dev-util/cmake-bootstrap, keep it in sync with dev-util/cmake, >make sure both packages co-exists with full disjoint operation, >i.e. zero file conflicts + zero cross package file usage (tricky?). > > B) Introduce USE flag "system-expat" to CMake similar to existing >flag "system-jsoncpp", have it off by default, keep reminding >CMake upstream to update their bundle > > I favor (B) by more than just a bit. Does anyone have strong concerns > against moving in the dev-util/cmake[-system-expat] (B) direction? Is > it acceptable if I make those changes to the CMake ebuild myself? > It violates the policy on bundled libraries. What's worse, the awful USE flags solution means that most of the Gentoo devs end up using bundled libraries just because people are manually required to figure out what to do in order to disable them. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Hey! Thanks everyone for your thoughts so far! >From what I heard, these two options seem realistic to me: A) Ask the KDE team for help with teaming up on a new package dev-util/cmake-bootstrap, keep it in sync with dev-util/cmake, make sure both packages co-exists with full disjoint operation, i.e. zero file conflicts + zero cross package file usage (tricky?). B) Introduce USE flag "system-expat" to CMake similar to existing flag "system-jsoncpp", have it off by default, keep reminding CMake upstream to update their bundle I favor (B) by more than just a bit. Does anyone have strong concerns against moving in the dev-util/cmake[-system-expat] (B) direction? Is it acceptable if I make those changes to the CMake ebuild myself? Thanks again Sebastian
[gentoo-dev] Last rites: PHP 7.1 and required packages
# Brian Evans (2019-12-19) # PHP 7.1 is end of life and has security issues Bug 703326 # Associated packages are not ready for new versions tracked in bug 702110 # Removal in 30 days dev-lang/php:7.1 dev-php/pecl-cassandra signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On 19.12.19 14:32, Rolf Eike Beer wrote: > These things _are_ updated regularly To be fair they update because I keep opening update requests: https://gitlab.kitware.com/cmake/cmake/issues?scope=all&utf8=%E2%9C%93&state=closed&search=expat+update
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Am 2019-12-18 22:44, schrieb Francesco Riosa: Il giorno mer 18 dic 2019 alle ore 22:03 Sebastian Pipping ha scritto: CMake bundles a (previously outdated and vulnerable) copy of expat so I'm not sure if re-activating that bundle — say with a new use flag "system-expat" — would be a good thing to resort to for breaking the cycle, with regard to security in particular. Pushing gently upstream to upgrade bundled expat copy would (at least temporarily) fix the issue and also benefit other use cases. Maybe they are Gentoo friendly they also release quite often, which would fix the problem soon This is in CMake 3.16.0: commit 50bc359184472700e9776a0a9d6f7e06ea82b9ce Author: Brad King Date: Mon Nov 11 10:44:17 2019 -0500 expat: Update CMake build for 2.2.9 commit b63a5c88a2089494e53f22f83db1925435161934 Merge: 512fabaa9d 1712885b4f Author: Brad King Date: Mon Nov 11 10:42:32 2019 -0500 Merge branch 'upstream-expat' into update-expat * upstream-expat: expat 2019-09-25 (a7bc26b6) These things _are_ updated regularly, but in case something is missed just file a bug at gitlab.kitware.com. All these bundled thing bumps are scripted as far as possible, so the actual overhead is quite small. Eike
Re: [gentoo-dev] Packages up for grabs due to slis' retirement
On Thu, 2019-12-19 at 14:54 +1300, Kent Fredric wrote: > On Wed, 18 Dec 2019 22:35:40 + > Michael 'veremitz' Everitt wrote: > > > There is some very strange wrapping/formatting in this message, was that > > intentional? > > If I had to guess, I'd say the word-wrap length was accidentally set to > "8" instead of "80". > This is Evolution. Sometimes weird stuff just happens. You can't expect predictable behavior from optimistic programmers these days. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On Wed, 2019-12-18 at 23:58 +, Sergei Trofimovich wrote:
> On Wed, 18 Dec 2019 22:02:47 +0100
> Sebastian Pipping wrote:
>
> > Hi all,
> >
> >
> > I noticed that dev-util/cmake depends on dev-libs/expat and that
> > libexpat upstream (where I'm involved) is in the process of
> > dropping GNU Autotools altogether in favor of CMake in the near future,
> > potentially the next release (without any known target release date).
> >
> > CMake bundles a (previously outdated and vulnerable) copy of expat so
> > I'm not sure if re-activating that bundle — say with a new use flag
> > "system-expat" — would be a good thing to resort to for breaking the
> > cycle, with regard to security in particular.
> >
> > Do you have any ideas how to avoid a bad circular dependency issue for
> > our users in the future? Are you aware of similar problems and
> > solutions from the past?
>
> Some other distributions provide two packages to break the cycle.
> Example Gentoo solution would be: "cmake.ebuild" depends on "expat.ebuild",
> "expat.ebuild" depends on "cmake-with-bundled-expat.ebuild".
>
I actually think this is the cleanest solution of all. To be more
specific, create dev-util/cmake-bootstrap that either includes bundled
dependencies (let's not forget about jsoncpp here) and installs into
some dedicated prefix (e.g. /usr/lib/cmake-bootstrap).
Then you'd have expat and jsoncpp would BDEPEND:
|| ( dev-util/cmake-bootstrap dev-util/cmake )
and the ebuild would do something like, roughly:
has_version -b dev-util/cmake ||
local -x PATH=${BROOT}/usr/lib/cmake-bootstrap/bin:${PATH}
Since we don't need blockers there, Portage should be able to resolve
the depgraph peacefully and pull both packages in gracefully. You
wouldn't have to do anything else in further revdeps. The bootstrap
package would be safely isolated from the other revdeps, and it would be
depcleaned once other packages pull in regular cmake.
I can make a proof-of-concept based on jsoncpp if you like.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
