On Mon, May 30, 2016 at 02:11:31PM -0700, Paul Rogers wrote:
> > I do not think this is reasonable for a couple of reasons. First, we
> > do not have the manpower to spend the time to figure that out. Second,
> > it creates a maintenance nightmare because at every package update
> > (often 3-5 per day, sometimes more), we would potentially need to to
> > update the dependent packages for changes.
>
> Really? OK. I don't know your process. I figured it'd be trivial--as
> you're updating each package, on each page you put a link to its
> dependencies, just "click on it" and add the anchor pointing back.
Well, I didn't understand your original post - except to note that
it implied some sort of extra work by an editor when updating a
page. But now you seem to be implying that what you want is a link
to dependencies (e.g. for firefox, gtk+-2 or gtk+-3 - among many
other deps). But we already have that ('Required', 'Recommended',
'Optional').
I suspect you actually want the reverse: "Packages in the book which
can use this package". I'll tell you now, it ain't going to
fly.
When I edit a page to move to a new version, I typically (but not
always) throw the new version into a new build so I can have some
confidence it works with the packages I care about. After that, I
will try to review dependencies (looking for additions or
deletions), perhaps change how I build it in the light of new
options, get to a set of build instructions I'm confident in, perhaps
look at tests, and then measure it (space, time) and try to notice
new programs or libraries, or dependencies, which need to be
documented. Other editors will be doing much the same.
And now you seem to think it will be trivial for us to initially
add a list of packages which can use this package, and on subsequent
edits review that list for things which have dropped out or started
to use this (arguably, if we did that then additions should be added
when a package starts to use a dependency iff that dependency has a
list of packages which can use it.. Also, that list will waste a lot
of space on the page.
I repeat - what we really need is more editors : for that people
need a reasonable connection, an ability to use the book's docbook
and subversion (e.g. by initially offering patches), and
(critically, in the light of the last year) an ability to work with
other editors without denigrating them. Also, at a minimum the
current release of LFS and BLFS. Having spare time and a fast
machine also help.
For your problem - start with the applications you want to have,
work out their dependencies iteratively until you get back to base
LFS. Then come up with a sequence (build order) which suits what
you are doing. And expect to change that order from time to time.
e.g. I saw a report on the Mesa list that Python3 will be required
(perhaps it already is, my versions are a month old) - until now I
have always built Mesa for Xorg in a comparativly early part of my
desktop BLFS builds, with Python2 built even before I reboot (used
to be later, but things changed) but I have ignored Python3 until I'm
throwing in dependencies for libreoffice much later in the build.
Plus ça change, plus c'est la même chose.
ĸen
--
I had to walk fifteen miles to school, barefoot in the snow. Uphill both ways.
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
