Some packages I'd like to see added
jeremy at jutley.org
Thu Dec 30 07:14:56 PST 2004
Randy McMurchy wrote:
> Jeremy Utley wrote:
>> Randy McMurchy wrote:
>> That was my intention right from the beginning of suggesting this -
>> after 6.0 is released. And, as I said, I'm more than willing to help
>> out by writing the initial pages for them, and submitting as patches
>> to the BLFS XML, as I've done with a couple of previous updates - I
>> hope doing this is helping you guys out a little - I know keeping
>> BLFS up to date is rather difficult, and with my frequent building, I
>> come across updates quite easily.
> Jeremy, please understand what I'm about to say is directed as
> a way to explain the BLFS process (as I understand it). I'm not
> directing these comments as an argument against you.
> There is more to updating a package than simply changing the
> version entity and ensuring it builds correctly. All of the
> below must happen before a version update is added to the
> 1. The build must be tested against the *exact* version of LFS
> that BLFS targets.
> 2. It must build successfully using all of the identified dependencies,
> and not have issues with any of these dependencies.
> 3. It must interact with any and all other packages that may utilize
> it at run-time.
> 4. The dependency list needs to be checked, both existing ones, and
> any possible new ones. These change all the time. Not every package,
> every time, but enough to warrant a very thorough read of README,
> INSTALL and the output from ./configure --help.
> 5. The installed programs need to be checked over, and added/removed
> as required.
> 6. The text needs to be checked over for any changes in the
> operation and/or utilization of the package.
> There's probably more, but I think you get the picture. Even if you
> send in a patch, an editor needs to accomplish all of the above before
> applying it. Right?
My opinion would be that a lot of this stuff is essential for a release,
but not necessarily for the SVN version of BLFS. However, if someone
who's submitting a new package, or an update to a package, as a patch;
is aware of what needs to be done (like you've just made me); and is a
trusted, long-time member of the LFS community, then I believe the patch
could be applied without further checking by the BLFS development team.
>>> I have a patch for the Fortune Makefile, I suppose I could write
>>> a hint that would just take me a few minutes. I too agree, that
>>> there's really no place in BLFS for Fortune.
>> I don't know what fortune package you guys are building - I've always
>> used the fortune-mod-9708 referenced in the old hint, and that
>> particular package has a few different options that are passed into
>> the makefile to control the build.
> I made a patch. It was easier to me. And the version you reference
> is the one referenced as the xscreensaver depend.
>> But yes, fortune would probably fit best in chapter 10...and if you
>> don't want Xscreensaver to keep saying "/usr/games/fortune - no such
>> file or directory", it should probably be added. Because of this,
>> I'd almost consider fortune to be an essential thing for Xscreensaver.
> I will do some checking and see what it takes to disable fortune
> by default (if possible) from xscreensaver. If this is possible,
> I'll get it added into BLFS before the release.
I think you would have to patch out any and all screensavers that
utilize fortune. The better solution in the interim, IMHO, is to point
right at the fortune hint for the 6.0 release, letting the user know
what to expect if they choose not to install it, and adding fortune in
after 6.0's release.
More information about the blfs-dev