Bug 144678 - simplify packaging: nuke libtidy
simplify packaging: nuke libtidy
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: tidy (Show other bugs)
3
All Linux
medium Severity low
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-10 11:59 EST by Rex Dieter
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-12 17:04:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2005-01-10 11:59:38 EST
I'll re-iterate my original request since a package update did occur
since then:

See
http://bugzilla.fedora.us/show_bug.cgi?id=2071

Especially since no external software in Extras (that I'm aware of)
uses libtidy, there's not much point in packaging it separately or
including the static lib.
Comment 1 Ville Skyttä 2005-01-10 15:42:41 EST
My opinion since http://bugzilla.fedora.us/show_bug.cgi?id=2071#c2 has
not changed.

Is the package broken somehow?

Is there a real world problem that would be solved by combining the
executables and shared libs in one package?  I still think that
separating them is good packaging practice in general.

Why exclude the static lib from this devel package given that
including static libs in devel packages is the standard practice
elsewhere in the distro and in extras?  The vast majority of static
libs in FC and FE are not used by other FC/FE packages; that does not
make them useless.

I'm not going to make potentially backwards incompatible changes
purely based on opinions.  Such changes need to be backed by strong
(usually technical) arguments dictating the necessity.

(FWIW, I've heard that Perl bindings to libtidy are in the works.)
Comment 2 Rex Dieter 2005-01-10 16:04:29 EST
Not fair, you've turned my own arguement against me.  (-:  

(--disable-static aside, I care less about that).

I would argue that one should not create libfoo subpackages unless
there is good reason.  In this case, I see no good reason (and
maintaining the status-quo isn't good enough either, IMO).  Good
reasons, in general, include:
1.  Do you need multiple versions installed?  (no)
2.  Do you save (significant) bloat by splitting things and not
forcing the whole monolithic package to be installed?  (no)
3.  Does it simplify package dependancies?  (no)

By splitting, you're also introducing possible future bloat, as the
old libfoo0 will never get automatically removed/upgraded when libfoo1
comes around.

Further, I've seen yum buglets appear from extraneous package
splitting as well.  See 
http://lists.atrpms.net/pipermail/repo-coord/2005-January/000450.html
as at least one case where Axel's splitting of libfooXX packages has
led to yum-bugginess.

I don't see how subpackage simplification would incur any breakage of
backward compatibility, either, as long as 
1.  no other packages currently depend on (parts of) this one
2.  one carefully uses versioned Obsoletes/Provides.

Now, if you still think libtidy is a good idea, that's fine, I'll shut
up and go on my merry way.
Comment 3 Ville Skyttä 2005-01-12 17:04:18 EST
One more reason: optimization; in some cases building optimized
libraries results in improved performance, and it simplifies things to
be able to only ship/rebuild only the optimized libs.

Yet one more: keeping out unneeded executables from $PATH has marginal
value.

I get your point, in the end there's not really much gained in the
tidy package by separating the libs and executables.  

But I still happen to think that in general such a split is at the
very least worth considering, and more often than not applying.  There
are many potential good things in that arrangement, and I don't see
any real problems with it.  (Note that I have not, and don't intend
to, go into the libtidyN, libtidyM business unless needed, that's
another issue).

So, I still fail to see the real need to or benefit of changing things
by bundling tidy and libtidy into one package, and won't do that now.
 Your comments are appreciated though; and I'll reconsider this
package arrangement if someone convinces me there's a problem to be
solved.

Note You need to log in before you can comment on or make changes to this bug.