3:43 a.m.
Why were critpath flags set on Emacs and Guile?
Cheers,
--
Jan Synacek
Software Engineer, Red Hat
4:05 a.m.
Hi,
On Fri, Oct 21, 2016 at 2:13 PM, Jan Synacek <jsynacek(a)redhat.com> wrote:
Why were critpath flags set on Emacs and Guile?
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.
4:22 p.m.
On Fri, Oct 21, 2016 at 02:35:13PM +0530, Parag Nemade wrote:
and emacs package was added because of @core group
@core group installs iputils -> libidn -> emacs-filesystem
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
8:24 p.m.
On Fri, Oct 21, 2016 at 10:22:14PM +0100, Richard W.M. Jones wrote:
On Fri, Oct 21, 2016 at 02:35:13PM +0530, Parag Nemade wrote:
> and emacs package was added because of @core group
> @core group installs iputils -> libidn -> emacs-filesystem
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'?)
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
8:16 a.m.
New subject: -filesystem packages (was: Re: Critpath flags on Emacs and Guile)
On Sat, 22 Oct 2016 01:24:57 +0000, Zbigniew Jędrzejewski-Szmek 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.
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.
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.
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.
6:18 a.m.
On Fri, Oct 21, 2016 at 9:43 AM, Jan Synacek <jsynacek(a)redhat.com> wrote:
Why were critpath flags set on Emacs and Guile?
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
6:30 a.m.
On 21/10/16 12:18, Peter Robinson 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).
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
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
10:23 a.m.
Tom Hughes wrote:
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
Why are these not in some emacs-libidn subpackage? Not all the world uses
Emacs!
Ctrl-X Ctrl-C,
Kevin Kofler
8:43 a.m.
On Fri, 21 Oct 2016 17:23:54 +0200
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Tom Hughes wrote:
> 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
Why are these not in some emacs-libidn subpackage? Not all the world
uses Emacs!
It used to do:
https://bugzilla.redhat.com/show_bug.cgi?id=1234563
Paul.
8:40 p.m.
Paul Howarth wrote:
It used to do:
https://bugzilla.redhat.com/show_bug.cgi?id=1234563
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
6:31 a.m.
On Fri, 21 Oct 2016 13:18:38 +0200, Peter Robinson wrote:
guild would be because it's a dep of a dep of gdb-headless
guile
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
8:21 a.m.
On Fri, Oct 21, 2016 at 01:31:25PM +0200, Jan Kratochvil wrote:
On Fri, 21 Oct 2016 13:18:38 +0200, Peter Robinson wrote:
> guild would be because it's a dep of a dep of gdb-headless
guile
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.
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
8:23 a.m.
On Fri, Oct 21, 2016 at 2:21 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Fri, Oct 21, 2016 at 01:31:25PM +0200, Jan Kratochvil wrote:
> On Fri, 21 Oct 2016 13:18:38 +0200, Peter Robinson wrote:
> > guild would be because it's a dep of a dep of gdb-headless
> guile
>
> 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.
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.)
Or just not care if they're critpath? I'm not sure what the problem is.
9:55 a.m.
On Fri, Oct 21, 2016 at 02:23:47PM +0100, Peter Robinson wrote:
On Fri, Oct 21, 2016 at 2:21 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> On Fri, Oct 21, 2016 at 01:31:25PM +0200, Jan Kratochvil wrote:
>> On Fri, 21 Oct 2016 13:18:38 +0200, Peter Robinson wrote:
>> > guild would be because it's a dep of a dep of gdb-headless
>> guile
>>
>> 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.
>
> 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.)
Or just not care if they're critpath? I'm not sure what the problem is.
Additional constraints on updates.
Zbyszek
10:18 a.m.
On 21 October 2016 at 10:55, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Fri, Oct 21, 2016 at 02:23:47PM +0100, Peter Robinson wrote:
> On Fri, Oct 21, 2016 at 2:21 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
> > On Fri, Oct 21, 2016 at 01:31:25PM +0200, Jan Kratochvil wrote:
> >> On Fri, 21 Oct 2016 13:18:38 +0200, Peter Robinson wrote:
> >> > guild would be because it's a dep of a dep of gdb-headless
> >> guile
> >>
> >> 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.
> >
> > 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.)
>
> Or just not care if they're critpath? I'm not sure what the problem is.
Additional constraints on updates.
Just say it.. no one wants to admit that emacs is needed for an OS to
be operational :).
--
Stephen J Smoogen.
2768
days inactive
2772
days old
15 comments
11 participants
participants (11)
-
Jan Kratochvil -
Jan Synacek -
Kevin Kofler -
Michael Schwendt -
Parag Nemade -
Paul Howarth -
Peter Robinson -
Richard W.M. Jones -
Stephen John Smoogen -
Tom Hughes -
Zbigniew Jędrzejewski-Szmek