DevHeads.net

Critpath flags on Emacs and Guile

Why were critpath flags set on Emacs and Guile?

Cheers,

Comments

Re: Critpath flags on Emacs and Guile

By Peter Robinson at 10/21/2016 - 07:18

On Fri, Oct 21, 2016 at 9:43 AM, Jan Synacek < ... at redhat dot com> wrote:
Because they get pulled into builds for core deliverables. In the
case of emacs I believe it's because emacs-filesystem gets pulled in
due to libidn (I've no idea why libidn needs that and I'd love to get
that dep removed).

guild would be because it's a dep of a dep of gdb-headless and make
(not sure if make is in the default installs)

Peter

Re: Critpath flags on Emacs and Guile

By Jan Kratochvil at 10/21/2016 - 07:31

On Fri, 21 Oct 2016 13:18:38 +0200, Peter Robinson wrote:
libguile-2.0.so.22 is DT_NEEDED - as shown by ldd.

Easy way would be to make gdb-headless a separate binary/build.

Less easy way would be to dlopen() libguile from gdb and keep there some stub
with dlsym()ed pointers to functions. Or maybe provide weak symbols all
pointing to a function dlopen()ing libguile and so the weak symbols would get
overriden by real symbols from libguile. Or is solved by some project?

Not sure if that guile dependency is such an issue.

Jan

Re: Critpath flags on Emacs and Guile

By Zbigniew =?utf-... at 10/21/2016 - 09:21

On Fri, Oct 21, 2016 at 01:31:25PM +0200, Jan Kratochvil wrote:
Can't we instead add fake Provides: this-package-is-not-critpath
and ignore such packages from the script which makes them critpath?
This seems like a better solution than doing ugly things like dlopen
(and breaking automatic Requires, etc.)

Zbyszek

Re: Critpath flags on Emacs and Guile

By Peter Robinson at 10/21/2016 - 09:23

On Fri, Oct 21, 2016 at 2:21 PM, Zbigniew Jędrzejewski-Szmek
< ... at in dot waw.pl> wrote:
Or just not care if they're critpath? I'm not sure what the problem is.

Re: Critpath flags on Emacs and Guile

By Zbigniew =?utf-... at 10/21/2016 - 10:55

On Fri, Oct 21, 2016 at 02:23:47PM +0100, Peter Robinson wrote:
Additional constraints on updates.

Zbyszek

Re: Critpath flags on Emacs and Guile

By Stephen John Smoogen at 10/21/2016 - 11:18

On 21 October 2016 at 10:55, Zbigniew Jędrzejewski-Szmek
< ... at in dot waw.pl> wrote:
Just say it.. no one wants to admit that emacs is needed for an OS to
be operational :).

Re: Critpath flags on Emacs and Guile

By Kevin Kofler at 10/24/2016 - 21:35

Stephen John Smoogen wrote:
Yes, "an OS", the operating system Emacs. ;-) Any other OS can do just fine
without it. :-p

Kevin Kofler

Re: Critpath flags on Emacs and Guile

By Tom Hughes at 10/21/2016 - 07:30

Because it's packaging some emacs extensions:

% rpm -ql libidn.x86_64 | fgrep emacs
/usr/share/emacs/site-lisp/libidn
/usr/share/emacs/site-lisp/libidn/idna.el
/usr/share/emacs/site-lisp/libidn/idna.elc
/usr/share/emacs/site-lisp/libidn/punycode.el
/usr/share/emacs/site-lisp/libidn/punycode.elc

Tom

Re: Critpath flags on Emacs and Guile

By Kevin Kofler at 10/21/2016 - 11:23

Tom Hughes wrote:
Why are these not in some emacs-libidn subpackage? Not all the world uses
Emacs!

Ctrl-X Ctrl-C,
Kevin Kofler

Re: Critpath flags on Emacs and Guile

By Paul Howarth at 10/22/2016 - 09:43

On Fri, 21 Oct 2016 17:23:54 +0200

It used to do:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1234563" title="https://bugzilla.redhat.com/show_bug.cgi?id=1234563">https://bugzilla.redhat.com/show_bug.cgi?id=1234563</a>

Paul.

Re: Critpath flags on Emacs and Guile

By Kevin Kofler at 10/24/2016 - 21:40

Paul Howarth wrote:
That "bug" report is just totally backwards, this ought to be changed back
(and if other packages were similarly "improved", they need to be reverted,
too).

Kevin Kofler

Re: Critpath flags on Emacs and Guile

By =?UTF-8?Q?Parag... at 10/21/2016 - 05:05

Hi,

On Fri, Oct 21, 2016 at 2:13 PM, Jan Synacek < ... at redhat dot com> wrote:
I think guile package was added because of @critical-path-base
@critical-path-base installs rpm-build -> gdb-headless -> guile

and emacs package was added because of @core group
@core group installs iputils -> libidn -> emacs-filesystem

Regards,
Parag.

Re: Critpath flags on Emacs and Guile

By Richard W.M. Jones at 10/21/2016 - 17:22

On Fri, Oct 21, 2016 at 02:35:13PM +0530, Parag Nemade wrote:
Coincidentally when I was doing the RISC-V bring up, I really wished
that emacs-filesystem had been a separate package (or maybe just part
of 'filesystem'?)

Rich.

Re: Critpath flags on Emacs and Guile

By Zbigniew =?utf-... at 10/21/2016 - 21:24

On Fri, Oct 21, 2016 at 10:22:14PM +0100, Richard W.M. Jones wrote:
Probably better to just drop the -filesystem subpackage and make all dependent
packages co-own that dir. Those -filesystem packages are a remnant of time
before repoquery could be used to easily find all packages that use some
directory. IMHO the rules that recommend -filesystem packages or similar
labour-intensive solutions over simply co-owning the directory are a total
waste of package time.

Zbyszek

-filesystem packages (was: Re: Critpath flags on Emacs and Guile

By Michael Schwendt at 10/22/2016 - 09:16

Unrelated.

Original repoquery is very old. And before repoquery, there have been
various scripts to query remote repositories OR even create and query an
RPMDB for all packages in Rawhide, for example. Tons of directory problems
have been found and reported without and before repoquery.

The -filesystem subpackage part of the guidelines has been enhanced
multiple times long after availability of repoquery.

The guidelines serve a simple purpose: Avoid co-owning directories as much
as possible, because packages get directory ownership and/or permissions
wrong _again and again_.

The larger a shared directory tree is, the more it makes sense to put it
into a separate -filesystem subpackage. But let two packagers create a new
package for something from scratch, and they will come up with a different
solution, such as a different set of subpackages and even different names
for the subpackages.

Even with tools like repoquery, it has not been easy for other packages to
understand subpackage concepts, such as whether and when to add an
explicit dependency on a -common subpackage. The next version upgrade,
and suddenly the packagers removed that subpackage again or filled it with
different files.

It cannot be pointed out often enough, packaging guidelines would need to
be much more detailed in order to remove all the ambiguities that are left
today. One could fill a book with many pages.

I'd like to see a move towards reducing the [sub]package number. I'd
prefer more monolithic packages for large applications, no matter whether
it would increase the install size and pull in more dependencies, but this
would need to be decide by project leadership and not individual
packagers. Dozens to hundreds of tiny packages in the KiB size range is
nuts, and almost 5000 packages in the texlive- namespace is sheer madness.