[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [REPOST!] Split out e2fsprogs sublibraries



On Tuesday, May 12 2009, Daniel P. Berrange said:
> On Tue, May 12, 2009 at 08:52:01AM -0500, Eric Sandeen wrote:
> > Richard W.M. Jones wrote:
> > > [I posted this before, but no one replied, so sending again to
> > > fedora-devel-list]
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=225406#c7
> > > 
> > > I would like to propose that e2fsprogs generate four subpackages for
> > > the independent libraries that it contains.  These four libraries are
> > > used by other packages that don't need the whole of e2fsprogs-devel
> > > (eg. krb5_workstation uses libss, qpid uses libuuid, and many programs
> > > use libcom_err).
> > 
> > I'm generally open to the suggestion, but last time I had this concern...
> > 
> > > The next problem I see is that by putting things like blkid, uuidgen,
> > > compile_et, mk_cmds into the lib$FOO packages, they are now no longer
> > > multilib-safe; the binaries will collide.

The binaries won't end up colliding as rpm is (sort of) smart about
handing conflicting multilib binaries like this, but ...

> > is this going to be a subpackage-explosion?  for example:
> > 
> > uuid.rpm  (with the binary tool(s))
> > uuid-libs.rpm
> > uuid-devel.rpm
> > 
> > and so on for each of the above binary+libs?
> 
> IMHO, having separate sub-packages for each of the command line tools
> is overkill. Just put the libraries in -libs & -devel, but keep all
> the binaries in e2fsprogs. This would avoid any multilib issues with
> binaries, and keep the number of sub-packages sane.

This feels more reasonable anyway.  Having binaries in a lib package is
just a little weird

Jeremy


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]