Re: tlug: PJE

[Scott Stone <sstone@example.com>]

On Fri, 21 Aug 1998, Stephen J. Turnbull wrote:

> >>>>> "Scott" == Scott Stone <sstone@example.com> writes:
> 
>     Scott> On Fri, 21 Aug 1998, Chris Sekiya wrote:
> 
>     >> Headers belong in library-devel.  Shared library belongs in
>     >> library-(null).  Static library belongs in library-static.
>     >> Everything nicely labelled, and none of this
>     >> have-to-install-the-static-library-to-get-anything-to-compile
>     >> nonsense.
> 
> I like this idea.  However, none of the existing package managers can
> handle this if pushed just a little bit.  (OK, they can handle it, but 
> their users can't.  I haven't looked at Debian APT aka dselect-TNG,
> but it's still hot-air-ware, a little more baked than vaporware.)
> 
> The problem is that Debian already has 1500+ packages in hamm/main,
> 300+ in hamm/non-free, 150+ in hamm/config, and dselect is getting
> more than a little unwieldy.  I won't even try to compare any of the
> RPM managers, they're all worse (sorry, Scott, but you know what I'm
> complaining about).

actually, splitting this up isn't that hard.  It's just time consuming.
RPM can handle it without difficulty.  You'd just have to make sure that
the library-static package depends on library-devel (ie, the .a is useless
without the headers..) and library-devel SHOULD depend on library-(null)
as well, since the .so file owned by library-devel would be a symlink to
the .so.major.minor file in library-(null).  Actually, RPM would take care
of THAT dependency automatically, I think.

> 
> Now, I know some people who are making RPMs of XEmacs packages.
> XEmacs already has over 100 Lisp packages.  You could also imagine
> breaking up Perl and Python and TeX and the FSF's Emacs etc, etc like
> that.  This is just much too big for the DB/presentation capabilities
> of current PMSs.

Xemacs doesn't really enter into it, since there's no libXEmacs for
development, last I checked?  XEmacs development is done in Elisp, right?

> I don't think that's what he said.  He is arguing against mixing
> distributions (even different versions of the same distribution).
> Just like you do:  TL-2.0 (beta, at least) required /usr to be wiped
> to be confident that it would work right, at least that's what I
> remember you telling me at the time.
> 
> It certainly _didn't_ work right for me until I did that ;-)

I believe that it was your experience in this matter that caused me to put
that policy in the docs in the first place :)  I never did figure out
exactly what was causing that problem, but it was probably bad packages in
1.0 that were doing it.  I was up to my ears in work (24 hour days, etc)
at the time doing other number-one-top-critically-important things at the
time.. sigh.. 2.0 will be upgradable, though, I'm pretty sure.

> 
>     Scott> BTW, I like your suggestion of library-(null),
>     Scott> library-devel, library-static.  it'll take me a while to
>     Scott> implement that, though, unless you want to help, Chris :)
> 
> If you're going to do that, and they've implemented "recommends" or
> "suggests" in RPM, lib(null) should recommend lib-devel, and lib-devel's 
> blurb should explain why.

RPM doesn't do that internally, but I believe I put that into turbopkg, at
least on the group level.  If I haven't implemented it on the per-package
level, I'll do that too.

--------------------------------------------------
Scott M. Stone <sstone@example.com, sstone@example.com>
               <sstone@example.com>
Head of TurboLinux Development/Systems Administrator
Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)
http://www.pht.com		http://armadillo.pht.co.jp
http://www.pht.co.jp	        http://www.turbolinux.com


--------------------------------------------------------------
Next Nomikai: 18 September, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 10 October, Tokyo Station Yaesu central gate 12:30
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp