10:13 a.m.
On Wed, Jun 06, 2007 at 03:34:33PM +0200, Arnd Bergmann wrote:
On Wednesday 06 June 2007, Miroslav Lichvar wrote:
> On Tue, Jun 05, 2007 at 07:34:30PM -0400, Bernardo Innocenti wrote:
>
> This list is far too short, xterm-256color, gnome, teraterm, jfbterm,
> mrxvt and others should be included. I guess it will be pretty hard to
> select from descriptions so the extra terminfo package won't have to
> be installed by default.
Actually, we already have a small subset defined in /lib/terminfo,
as opposed to the full set that gets installed to /usr/share/terminfo.
Maybe it's enough to review the list of files in the former directory
and then use only those by default, with /usr/share/terminfo in an
optional package.
In /lib/terminfo should be only a minimal set that might be required
when doing system administration with /usr unmounted. Wondering how
xterm got there.
What now is in the ncurses package would then become
libncurses: {,/usr}/lib{,64}/*.so.* /lib/terminfo/*
ncurses-bin: /usr/bin/*, requires: libncurses.%{arch}
ncurses-data: /usr/share/terminfo/, requires: libncurses
ncurses: requires: ncurses-bin, ncurses-data.
Ok. Maybe I'd use a bit different naming instead:
ncurses-bin: bin/*
ncurses-base: lib*.so.* /etc/terminfo /lib/terminfo, some of /usr/share/terminfo
ncurses-terminfo: rest of /usr/share/terminfo
ncurses: requires: -bin -base -terminfo
How does this sound?
--
Miroslav Lichvar
1:24 p.m.
New subject: Splitting the ncurses RPM
Miroslav Lichvar (mlichvar(a)redhat.com) said:
Ok. Maybe I'd use a bit different naming instead:
ncurses-bin: bin/*
ncurses-base: lib*.so.* /etc/terminfo /lib/terminfo, some of /usr/share/terminfo
ncurses-terminfo: rest of /usr/share/terminfo
ncurses: requires: -bin -base -terminfo
How does this sound?
For sanity's sake on upgrades, leaving the libraries in the same
package name (multilib) would be best.
Bill
8:10 a.m.
New subject: Splitting the ncurses RPM
On Wed, Jun 06, 2007 at 02:24:57PM -0400, Bill Nottingham wrote:
Miroslav Lichvar (mlichvar(a)redhat.com) said:
> Ok. Maybe I'd use a bit different naming instead:
>
> ncurses-bin: bin/*
> ncurses-base: lib*.so.* /etc/terminfo /lib/terminfo, some of /usr/share/terminfo
> ncurses-terminfo: rest of /usr/share/terminfo
> ncurses: requires: -bin -base -terminfo
>
> How does this sound?
For sanity's sake on upgrades, leaving the libraries in the same
package name (multilib) would be best.
I'm confused, do you want to keep the libraries in ncurses package?
--
Miroslav Lichvar
9:48 a.m.
New subject: Splitting the ncurses RPM
Miroslav Lichvar (mlichvar(a)redhat.com) said:
> For sanity's sake on upgrades, leaving the libraries in the
same
> package name (multilib) would be best.
I'm confused, do you want to keep the libraries in ncurses package?
(This has nothing to to with OLPC, and everything to do with the distro)
If the libraries move to a different package, we end up with ncurses-devel/
ncurses-libs being multilib, instead of ncurses-devel/ncurses as we have
currently. This causes problems for upgrades with getting a no-longer-multilib
ncurses package off the system for the secondary arch. So, if possible,
keeping the libraries in the 'same' package as it was previously is preferred.
Bill
10:27 a.m.
New subject: Splitting the ncurses RPM
On Thu, Jun 07, 2007 at 10:48:39AM -0400, Bill Nottingham wrote:
Miroslav Lichvar (mlichvar(a)redhat.com) said:
> > For sanity's sake on upgrades, leaving the libraries in the same
> > package name (multilib) would be best.
>
> I'm confused, do you want to keep the libraries in ncurses package?
(This has nothing to to with OLPC, and everything to do with the distro)
If the libraries move to a different package, we end up with ncurses-devel/
ncurses-libs being multilib, instead of ncurses-devel/ncurses as we have
currently. This causes problems for upgrades with getting a no-longer-multilib
ncurses package off the system for the secondary arch. So, if possible,
keeping the libraries in the 'same' package as it was previously is preferred.
Ok, that makes sense. Unfortunately I don't see other way how to
create a subpackage that will be installed in upgrade and have
dependencies that would allow removing the subpackage.
--
Miroslav Lichvar
10:59 a.m.
New subject: Splitting the ncurses RPM
On Thu, 2007-06-07 at 10:48 -0400, Bill Nottingham wrote:
Miroslav Lichvar (mlichvar(a)redhat.com) said:
> > For sanity's sake on upgrades, leaving the libraries in the same
> > package name (multilib) would be best.
>
> I'm confused, do you want to keep the libraries in ncurses package?
(This has nothing to to with OLPC, and everything to do with the distro)
If the libraries move to a different package, we end up with ncurses-devel/
ncurses-libs being multilib, instead of ncurses-devel/ncurses as we have
currently. This causes problems for upgrades with getting a no-longer-multilib
ncurses package off the system for the secondary arch. So, if possible,
keeping the libraries in the 'same' package as it was previously is preferred.
Bill,
to be honest,
I think deciding the package shape based on the broken way we are
currently detecting multi-libs is a bad way to decide.
We should fix the way we detect multi-libs, not produce substandard
packaging to keep the current multi-libs detection process happy.
IMO,
Simo.
11:24 a.m.
New subject: Splitting the ncurses RPM
Simo Sorce wrote:
I think deciding the package shape based on the broken way we are
currently detecting multi-libs is a bad way to decide.
We should fix the way we detect multi-libs, not produce substandard
packaging to keep the current multi-libs detection process happy.
True, to a degree, but until the the multilib issue is addressed (which may
take some time), you need to make do the best you can. And "making do",
for now, is following Bill's advice (and I'd argue Bill's suggestion is in
no way substandard, with or without multilib considerations).
-- Rex
12:54 p.m.
New subject: Splitting the ncurses RPM
Simo Sorce (ssorce(a)redhat.com) said:
to be honest,
I think deciding the package shape based on the broken way we are
currently detecting multi-libs is a bad way to decide.
We should fix the way we detect multi-libs, not produce substandard
packaging to keep the current multi-libs detection process happy.
It's not a matter of changing the detection (getting the right packages
in the tree a multilib), it's a matter of making upgrades work when
package X is no longer multilib. That's significantly trickier.
Bill
1 p.m.
New subject: Splitting the ncurses RPM
On Thu, 2007-06-07 at 13:54 -0400, Bill Nottingham wrote:
Simo Sorce (ssorce(a)redhat.com) said:
> to be honest,
> I think deciding the package shape based on the broken way we are
> currently detecting multi-libs is a bad way to decide.
>
> We should fix the way we detect multi-libs, not produce substandard
> packaging to keep the current multi-libs detection process happy.
It's not a matter of changing the detection (getting the right packages
in the tree a multilib), it's a matter of making upgrades work when
package X is no longer multilib. That's significantly trickier.
It's not like we don't already have the problem, though. Adding to the
list in anaconda is simple enough and Seth has most of a yum plugin
written. Then we just have to move the list from being hard-coded in
anaconda to a separate metadata file that ends up in the repos
Jeremy
6172
days inactive
6173
days old
8 comments
5 participants
participants (5)
-
Bill Nottingham -
Jeremy Katz -
Miroslav Lichvar -
Rex Dieter -
Simo Sorce