Le 02/06/2012 18:00, Jeremy Huntwork a écrit :
> I'm going to start by jumping on the parser, since it will be
> necessary right away for any of this to work. My initial thoughts are
> to build one parser that can accept different output filters, for
> example, outputting to PKGBUILD files, or r
Le 02/06/2012 18:00, Jeremy Huntwork a écrit :
> I'm going to start by jumping on the parser, since it will be necessary
> right away for any of this to work. My initial thoughts are to build one
> parser that can accept different output filters, for example, outputting
> to PKGBUILD files, or rpm
On 6/1/12 9:31 AM, James Robertson wrote:
> Sure. Lets take sudo as an example. What could be considered a simple
> program has 8 optional dependencies with 4 being "off book". I think we
> ignore those 4 and worry only for the 4 "in book" optional
> dependencies. The build instructions in the m
o turn (B)LFS
> > into a binary distro. It is and always should be a cookbook so those
> > that want can still roll their own. I really think that this effort
> > should be a book development tool and cookbook for those wanting to
> > learn about package management. I
rt
> should be a book development tool and cookbook for those wanting to
> learn about package management. I think the current books stay as is
> and PM is another off-shoot like cLFS. The books should stay
> independent as they have different goals. I am thinking that we attempt
> to leve
so be noted
and clear that the purpose of this effort is not to turn (B)LFS into a
binary distro. It is and always should be a cookbook so those that want
can still roll their own. I really think that this effort should be a book
development tool and cookbook for those wanting to learn about packag
On 5/20/12 7:09 PM, Ken Moffat wrote:
> The more I think about this, the less happy I am. Point 2 doesn't
> really help editing BLFS as far as I can see (upgrading a package
> usually needs several builds - typically, for me, a first to see if
> it actually works when I use it, then others to ge
Le 22/05/2012 01:58, Armin K. a écrit :
> Also, I see you mention package managers ... For me, Debian's dpkg is
> the hardest one. debian/rules file uses Makefile syntax which I am not
> familiar with. Red Hat's rpm uses some kind of spec file which doesn't
> seem that hard to understand, but still
On 05/22/2012 01:27 AM, DJ Lucas wrote:
>
> It omits the core point of LFS...education. I dislike providing binary
> packages to users, but a working example of how to create those binary
> packages is something we've lacked for a long time, plus getting those
> packages that don't honor DESTDIR ex
On 05/20/2012 04:34 PM, Bruce Dubbs wrote:
Seems my phone ate my previous response...easier to type on a real
keyboard anyway.
> OK, then what's wrong with a tarball of binaries that we have created
> for this purpose? There could be a tarball of the base LFS system and
> then additional tarball
On 5/20/12 7:09 PM, Ken Moffat wrote:
[snip - a number of good, thoughtful questions]
I'm going to have to let your questions brew for a while before I can
reply to them. Perhaps someone else will have an opinion regarding them
in the meantime...
JH
--
http://linuxfromscratch.org/mailman/li
On 5/20/12 5:34 PM, Bruce Dubbs wrote:
> OK, then what's wrong with a tarball of binaries that we have created
> for this purpose? There could be a tarball of the base LFS system and
> then additional tarballs for certain packages or groups (e.g. xorg) of
> packages.
This method does not collect
make sure that
> when I say it builds and works with 7.1 it does, and to detect if
> any change in a newer LFS package has broken something along the way
> (nothing recent, but I can remember pain in a package from a grep
> update: something to do with manpages in a docbook package, I thin
On Sat, May 19, 2012 at 09:26:31AM -0400, Jeremy Huntwork wrote:
>
> Proposal:
>
> 1. Adjust LFS/BLFS to auto-generate build recipes for individual
> packages that a packaging tool can use to create binary packages with
> meta information included such as dependency tracking.
>
> 2. Store 'off
em where you can take LFS a a base,
and then build on top of it.
This situation seems to really speak to git, where it's easier to branch
off--and to decentralize, because any project based on LFS obviously still
needs the "trunk", but would allow "addons"--stuff like JH&
On Sun, May 20, 2012 at 04:34:11PM -0500, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
> >
> > I think perhaps the point is being missed here. The purpose of the
> > proposal (creating and providing binaries) isn't for the _reader's_ use,
> > (if someone found them and wanted to use them that's t
Jeremy Huntwork wrote:
> On 5/20/12 3:10 PM, Bruce Dubbs wrote:
>>> This exact reason, for the record, is why I really dislike binary
>>> distros. I *never* choose the same set of dependencies that are
>>> optional in the source, as the distro does. And because when they ran
>>> ./configure, they
On 5/20/12 2:18 PM, Bryan Kadzban wrote:
> In other words, I think it'd help to only use packages to simplify
> (mostly BLFS) testing, but make them semi-public for people who really
> want them. Don't use them at all in the actual build instructions (what
> would be the point? :-) ), but generat
On 5/20/12 3:10 PM, Bruce Dubbs wrote:
>> This exact reason, for the record, is why I really dislike binary
>> distros. I *never* choose the same set of dependencies that are
>> optional in the source, as the distro does. And because when they ran
>> ./configure, they added a --with-foo flag, the
Bryan Kadzban wrote:
> FWIW...
>
> DJ Lucas wrote:
>> Fortunately, that is not a deal breaker for me if the
>> readers get the same treatment (which seems to be the case), but this
>> does hard code optional dependencies for the pre-packaged installations.
>> This is both good and bad. From a d
FWIW...
DJ Lucas wrote:
> Fortunately, that is not a deal breaker for me if the
> readers get the same treatment (which seems to be the case), but this
> does hard code optional dependencies for the pre-packaged installations.
> This is both good and bad. From a development standpoint, it won't
On 5/19/12 5:27 PM, lfs-dev.neophyte_...@ordinaryamerican.net wrote:
> The "pacman" reference here is to https://wiki.archlinux.org/index.php/Pacman
> not http://pacman.com/en/
> Correct?
Haha. Yes, that's right. Unless you can find a way to package up
distributable packages with the arcade game.
On 5/19/12 7:29 PM, Bruce Dubbs wrote:
> Certainly you have the privs, but I would like to have the capability of
> doing make DESTDIR=$DEST without being root. I don't particularly like
> the developer saying "you have to be root to run install". It's my
> system, not the developer's.
I believe
Jeremy Huntwork wrote:
> On May 19, 2012, at 5:03 PM, Bruce Dubbs wrote:
>
>> DJ Lucas wrote:
>>
>>> I have long suggested that LFS and BLFS move to installations
>>> from DESTDIR (or equivalent)
>> I do use DESTDIR to check the installation of most packages, but there
>> are some where it just d
On Sat, May 19, 2012 at 12:27 PM, jhuntw...@lightcubesolutions.com wrote:
> On 5/19/12 1:21 PM, Baho Utot wrote:
>> I have in the past worked on LFS-6.8 and have a completed pacman build
>> for it.
>
> Nice!
>
>> Sharing the work using pacman would be great, maybe we can exchange notes?
>
> Assum
On May 19, 2012, at 5:03 PM, Bruce Dubbs wrote:
> DJ Lucas wrote:
>
>> I have long suggested that LFS and BLFS move to installations
>> from DESTDIR (or equivalent)
>
> I do use DESTDIR to check the installation of most packages, but there
> are some where it just doesn't work. Actually, any pac
On May 19, 2012, at 5:04 PM, Bruce Dubbs wrote:
>
> It's easy to create a tarball of binaries for a specific
> architecture (686, x86_64, etc) and extract that to an empty partition.
> A rebuild of the kernel, setting up grub, and a script to handle some
> specific things (fstab, ip address, etc)
Jeremy Huntwork wrote:
> Well, the way I saw this working out in my head - we don't really
> advertise the binary package repository, although it would be available
> for anyone to use. Hence, "semi-public". The focus would still be on the
> book and letting a user choose her own path. The opti
DJ Lucas wrote:
> I have long suggested that LFS and BLFS move to installations
> from DESTDIR (or equivalent)
I do use DESTDIR to check the installation of most packages, but there
are some where it just doesn't work. Actually, any package that decides
to do a chown or use the -g or -o opti
On 5/19/12 1:15 PM, DJ Lucas wrote:
> My hope is that build order is still a manual process where the user
> determines build order herself. Dependency checking is done only at
> build time and that optional deps remain optional. If there will be
> automation, how do we determine what optional deps
On 5/19/12 1:21 PM, Baho Utot wrote:
> I have in the past worked on LFS-6.8 and have a completed pacman build
> for it. I wanted to build a desktop system from LFS/BLFS but it was too
> much work for me. I have not gone further because BLFS is a beast as
> you say. I completed a server using LF
On 5/19/12 1:15 PM, DJ Lucas wrote:
> What separates LFS from say Arch, Gentoo, T2... at that point? No mile
> long USE flags or complex switching scripts I presume, but I know little
> about the other two. I've included some of their work in BLFS in the
> past, but that is about it.
Well, the way
true of the LiveCD project, and is the main reason why it
> sits dead today. It is difficult to maintain when there are no packaged
> binaries to draw from and the entire thing is a scripted source build.
>
> Let me just say now that because (B)LFS is primarily (and probably
> should always b
true of the LiveCD project, and is the main reason why it
> sits dead today. It is difficult to maintain when there are no packaged
> binaries to draw from and the entire thing is a scripted source build.
>
> Let me just say now that because (B)LFS is primarily (and probably
> should always b
ld.
Let me just say now that because (B)LFS is primarily (and probably
should always be) about educating, I don't think we should require
end-users to use package management. Mainly the proposal is intended to
assist in development. However, if we have taken the time to incorporate
PM in
On 8/2/10, Ken Moffat wrote:
before uninstalling in case I change my mind.
>
> Cool. You've obviously been bitten in the past. Based on my script
> that runs through my audio, video, and photo files every week to
> check if md5s exist, and generate them where they don't, I imagine
> this will
On 2 August 2010 15:56, linux fan wrote:
> I use a find-before and a find-after and then process the diff with
> awk which enables me to detect whether a file was new or modified. It
> only serves as a reality check before I start deleting (uninstall). By
> the way, I put the md5sum in the list wh
DJ Lucas wrote:
>
> Berkeley DB could be done easily enough I think.
Flat text files allow processing via command line tools such as grep,
sed, awk, perl, bash, etcetera. Does a DB require an esoteric API that
can get in someone's way?
>
> if everything were properly accounted for,
> prior to ins
On 07/31/2010 08:08 PM, Kevin Buckley wrote:
> On 1 August 2010 09:12, Bruce Dubbs wrote:
>
>> BTW, I once (IIRC around 2004) made a suggestion to scan the filesystem
>> after each package and store information about each package's files in a
>> DB. That kinda begs the question about how you get
On 1 August 2010 09:12, Bruce Dubbs wrote:
> BTW, I once (IIRC around 2004) made a suggestion to scan the filesystem
> after each package and store information about each package's files in a
> DB. That kinda begs the question about how you get a db installed for
> use. We really don't want to
On 1 August 2010 00:02, Jeremy Huntwork
wrote:
>
> I'm glad you like it, and that you got in there and dug around. I wish
> more people had done so. Of the ones that had passwords sent to them,
> only 4 or so actually logged in.
>
My inital feelings about the mail purporting to come from an
unlik
On 7/31/10 4:44 PM, DJ Lucas wrote:
> Unfortunately, most times anyway, a proof of concept must come first
> before anybody will listen. Take for instance Jeremy's
> community.lfs.org site for which this thread started. Most of us agree
> that the website is looking a little tired, but it took th
DJ Lucas wrote:
> Finally, we provide a fail safe if somebody makes a mistake during the
> process. I speak from experience, starting over sucks! I know, and I'm
> pretty sure that everyone can remember the dreaded "It would be easier
> to start over" response from years ago in LFS-Support. I h
f what is installed. Given the core goal of
LFS, I would think that alone would be reason to move forward with it.
Next, the difficult part of package management is contained in the book,
so that those who wish to do more than just tar up a destination can do
so. For instance, packages that do
rded, and the
> ownership is changed to the admin. This stops new packages from
> overwriting the files of another package, allows us to catalog
> installed package files (so ownership can be reverted for upgrades),
> and disallows root from modifying them without the FOWNER capability.
I created a package manager that doesn't overwrite (unless told to), logs
everything, checks library dependencies, runs
{(pre/pos)/(install/uninstall)} scripts, splits packages in
"bin/dev/lib/doc/dbg" flavors and works entirely transparent to the point
that if you remove the package manager fr
what I had intended on doing, just wondered if
there was something easier than having to add stuff to my existing
scripts.
Thanks to everyone who commented (though some of the comments weren't
relevant to my questions, such as using package-users - yuck!) and I'm
right back where I wa
Randy McMurchy wrote:
> Hi all,
>
> Though this topic may be borderline off-topic for the -dev lists, they
> have the most traffic, and just may be relevant.
>
> My question is this:
>
> How do others handle the situation where directories are created by
> a package during the package install, and
Randy McMurchy wrote:
>
> I realize I could keep my old logs from packages I've since removed and
> replaced, but I'm wondering how others do it.
>
I didn't...hadn't even considered it when logging installations. I've
since moved to DESTDIR so my latest logging scripts were destroyed (but
I'm
On Thu, Feb 12, 2009 at 4:16 PM, Randy McMurchy
wrote:
>
> How do others handle the situation where directories are created by
> a package during the package install, and then other packages install
> other files in these directories?
I don't consider directories when creating log files. After a
Hi all,
Though this topic may be borderline off-topic for the -dev lists, they
have the most traffic, and just may be relevant.
My question is this:
How do others handle the situation where directories are created by
a package during the package install, and then other packages install
other fil
Bruce Dubbs wrote:
> OK, I don't have time for studying it now, but I did misunderstand the
> proposal.
> I'll go back and study it some more.
>
I'm working on Gnome again right now, but I'll put up a copy of the book
in my home dir with the proposed changes on Friday evening if I have the
ti
DJ Lucas wrote:
> Woah..reading a bit too much into it. As David correctly pointed out,
> I'm only suggesting that creating the basic filesystem (sections
> 6.2-6.6) be reordered, or rather reworked.
>
> Creating packages at build time is the goal, however, the packages would
> be installed i
Bruce Dubbs wrote:
> DJ Lucas wrote:
>
>> Bruce Dubbs wrote:
>>
>>> Can you explain what you mean by "create the entire 'base'".
>>>
>>>
>> Again, looking at this from a packaging point of view, IMO, all files
>> and directories that are created manually should be together on one
On Wed, 17 Dec 2008 10:31:14 +
david zorg wrote:
> Bruce, i think you're misunderstanding DJ's proposal - it sounds to me
> like he's saying that if the creation of the file-system heirachy and
> the essential files for the final system was done all on one page of
> the book, it would make it
On Tue, 16 Dec 2008 20:03:14 -0600
Bruce Dubbs wrote:
> DJ Lucas wrote:
> > Bruce Dubbs wrote:
> >> Can you explain what you mean by "create the entire 'base'".
> >>
> > Again, looking at this from a packaging point of view, IMO, all
> > files and directories that are created manually should b
Hello there:
Maybe this is irrelevant and I hope I don't offend anyone...
I've been working on a LFS package manager that works out of the tools
available in the "tools" directory (plus rsync and file) and that I could
use to manage my LFS servers.
I used the union-fs tools and I believe I
DJ Lucas wrote:
> Bruce Dubbs wrote:
>> Can you explain what you mean by "create the entire 'base'".
>>
> Again, looking at this from a packaging point of view, IMO, all files
> and directories that are created manually should be together on one page
> so that a single package can be generated
Bruce Dubbs wrote:
> Can you explain what you mean by "create the entire 'base'".
>
Again, looking at this from a packaging point of view, IMO, all files
and directories that are created manually should be together on one page
so that a single package can be generated and called 'lfs-base' or
DJ Lucas wrote:
> chapter 4?
>
UGH. I was thinking that 6.2 was at the end of chapter 5. Anyway, the
request is to merge virtual file systems page with creating directories
and the last 3 of 6.6 so that all directories and files that are
manually created (with the exception of links that wi
DJ Lucas wrote:
> DJ Lucas wrote:
>> a technical reason not to create the entire 'base' while in chapter 4?
>>
> Oops, that should have been 'chapter 5'.
Can you explain what you mean by "create the entire 'base'".
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: htt
DJ Lucas wrote:
> a technical reason not to create the entire 'base' while in chapter 4?
>
Oops, that should have been 'chapter 5'.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/
Guys, while I'm waiting on my automated build to complete, I'm running
through a manual build on a second system that I have, in order to test
the idea of using a DESTDIR installation. I must say that it has been a
*long* time since I did a full manual build. Anyway, can anyone provide
a tech
to create package-specific
ownerships for the to-be-installed files, along the lines of one
strand of package
management that has appeared on here at times - the "username-per-package"
approach.
I've always appreciated that the username-per-package PM method was probably a
little too
Matthew Burgess wrote:
> As I'm sure you're already aware, Gordon, we have historically tried to stick
> to
> an entirely linear, no-optional-extras format to the book. As such, I would
> prefer it if we just went whole-heartedly into DESTDIR support, no ifs, buts
> or
> maybes :-).
>
In fa
On Mon, 08 Dec 2008 13:02:46 -0700, Gordon Schumacher <[EMAIL PROTECTED]> wrote:
> Gordon Schumacher wrote:
>> cat >> ~/.bash_profile <<
>> "EOF"
>> make_package() {
>> tar cf $1.tar.bz2 $PKGTEMP
>> }
>> EOF
...
>> if [ "$(type -t make_package)" == "function" ]; then
>> make DESTDIR=$PKGTEMP
Gordon Schumacher wrote:
> Gordon Schumacher wrote:
>> I think I have an even better idea: rather than putting *any*
>> package management commands in, what about something like this:
>>
>> If you would like to generate binary packages, you will need
>> to defin
Gordon Schumacher wrote:
> I think I have an even better idea: rather than putting *any* package
> management commands in, what about something like this:
>
> If you would like to generate binary packages, you will need to
> define a function that will be used to generate those p
Ivan Kabaivanov wrote:
> I was wondering if the devs are, perhaps, working behind the scenes on
> putting
> together some PM as per the long thread(s) from a few weeks ago. Is there
> still interest in and momentum behind this idea?
As almost always, I'm way behind reading this (and other) lis
Ivan Kabaivanov wrote:
> I was wondering if the devs are, perhaps, working behind the scenes on
> putting
> together some PM as per the long thread(s) from a few weeks ago. Is there
> still interest in and momentum behind this idea?
>
> Thanks,
> IvanK.
>
>
Hello,
I am not in the LFS team, b
Ivan Kabaivanov wrote:
> I was wondering if the devs are, perhaps, working behind the scenes on
> putting
> together some PM as per the long thread(s) from a few weeks ago. Is there
> still interest in and momentum behind this idea?
I think there is, but it's just actually a matter of stepping
I was wondering if the devs are, perhaps, working behind the scenes on putting
together some PM as per the long thread(s) from a few weeks ago. Is there
still interest in and momentum behind this idea?
Thanks,
IvanK.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linu
Gerard Beekmans wrote:
> If you feel you can talk about a potential PM candidate for LFS, please
> write up a document that outlines the following:
Slackware-like .tgz
> - it's strengths and weaknesses
+ It is very simple, and everybody is expected to understand the code.
- Out of the box, it
Alexander E. Patrakov wrote:
> Greg Schafer wrote:
>> Alexander E. Patrakov wrote:
>>> does it
>>> allow running arbitrary scripts on the DESTDIR contents before
>>> actually creating a package?
>> Um, I don't think so. However, while Pacman itself is written in C, the
>> "makepkg" portion of the s
Alexander E. Patrakov wrote:
> Some people do want to use LFS in production. There are only two ways to deal
> with this situation: make LFS work perfectly, or drive them away from LFS,
> e.g.,
> by including somewhere in the preface some concrete missing features that
> make
> LFS unsuitable
Alexander E. Patrakov wrote:
> Some people do want to use LFS in production. There are only two ways to deal
> with this situation: make LFS work perfectly, or drive them away from LFS,
> e.g.,
> by including somewhere in the preface some concrete missing features that
> make
> LFS unsuitable
I wrote:
> Greg Schafer wrote:
>> You seem to be striving for perfection. When I want all the bells and
>> whistles I run a mainstream distro.
>
> Without this, LFS is unsuitable for production use. Nevertheless, people
> want it. There are only two ways to deal with this situation: make LFS
> w
Alexander E. Patrakov wrote:
> Greg Schafer wrote:
>> You seem to be striving for perfection. When I want all the bells and
>> whistles I run a mainstream distro.
>
> Without this, LFS is unsuitable for production use.
Expletive! I use LFS all the time for production use without PM. Alex,
lab
Greg Schafer wrote:
> Alexander E. Patrakov wrote:
>> does it
>> allow running arbitrary scripts on the DESTDIR contents before
>> actually creating a package?
>
> Um, I don't think so. However, while Pacman itself is written in C, the
> "makepkg" portion of the system is a Bash script which allow
Dan Nicholson wrote these words on 03/05/08 11:22 CST:
> What package management requirements the book uses aren't really that
> important to me, which is why I didn't answer. I'd much rather just
> follow what the community wants.
What Dan said. (as an explanation why
On Wed, Mar 5, 2008 at 4:35 PM, Greg Schafer <[EMAIL PROTECTED]> wrote:
>
> You seem to be striving for perfection. When I want all the bells and
> whistles I run a mainstream distro. It is simply too labour intensive to
> have "the lot" on a self built system. I looked at the amount of effort
>
Alexander E. Patrakov wrote:
> 2008/3/4, Greg Schafer <[EMAIL PROTECTED]>:
>> [x] file conflict detection <-- essential feature
>> [x] simple BLFS style dependencies <-- essential feature
>> [x] pre/post install scripts <-- essential feature
>> [x] ability to build the whole distro as non-r
On Wed, 05 Mar 2008 09:54:37 -0700
Gerard Beekmans <[EMAIL PROTECTED]> wrote:
> > I really do disagree with this stance. As an educative, as well as
> > practical project, we should show at least one worked example. Just
> > like we do with SysVInit and the bootscripts (which several of us
> > d
On Wed, Mar 5, 2008 at 1:35 AM, Alexander E. Patrakov
<[EMAIL PROTECTED]> wrote:
> - It has a lot of legacy features that were oriented to the old
> versions of autoconf (see, for example, how the %makeinstall macro
> expands--BTW RedHat doesn't use this macro)
Nobody uses this anymore, but it
35%, and you can bring this down to
> 33% (just a joke - the error of estimating the error is of course
> larger than those 2%).
What package management requirements the book uses aren't really that
important to me, which is why I didn't answer. I'd much rather just
follow what
Gerard Beekmans wrote:
> The more we discuss it, the more PM becomes a focal point.
>
> We need a clearly defined list of pros, cons and technical explanations
> plus their limitations of each viable choice - all the information that
> a user needs to make an informed decision while keeping in m
> I really do disagree with this stance. As an educative, as well as
> practical project, we should show at least one worked example. Just
> like we do with SysVInit and the bootscripts (which several of us
> don't ever use any more). No one has to use the example, but the
> example itself shows
; [X] I use LFS as my primary Linux system
> [X] I use LFS on more than one PC (including virtual machines)
> [ ] I deviate a lot from LFS (not counting package updates as deviations)
> [X] I deviate a lot from BLFS (not counting package updates as deviations)
>
> I use the following
2008/3/5, Gerard Beekmans <[EMAIL PROTECTED]>:
> If you feel you can talk about a potential PM candidate for LFS, please
> write up a document that outlines the following:
OK, deb--in my opinion, not a candidate at all. But let's have it just
for comparison.
> - it's strengths and weaknesses
do is inform the user of all the main
> stream and (perhaps) some of the not-so-mainstream options out there.
Currently we do exactly that on the
http://www.linuxfromscratch.org/lfs/view/development/chapter06/pkgmgt.html
page--yet it is useless, because one of the mainstream methods of
pa
DJ Lucas wrote:
> please ream my response
*read
LOL, and on that note, good night.
-- DJ
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
TheOldFellow wrote:
> On Tue, 04 Mar 2008 22:11:53 -0700
> Gerard Beekmans <[EMAIL PROTECTED]> wrote:
>
>> The more we discuss it, the more PM becomes a focal point. I agree with
>> Greg Schafer in that the actual choice of PM is a user's choice in the
>> end and shouldn't matter.
>>
>> About al
On Tue, 04 Mar 2008 22:11:53 -0700
Gerard Beekmans <[EMAIL PROTECTED]> wrote:
> The more we discuss it, the more PM becomes a focal point. I agree with
> Greg Schafer in that the actual choice of PM is a user's choice in the
> end and shouldn't matter.
>
> About all we should attempt to do is i
2008/3/5, Gerard Beekmans <[EMAIL PROTECTED]>:
> Do you have a running tally on this thread so-far, Alexander? I know,
> some 30 replies hardly counts as a cross-section of the LFS community,
> but at least it's a start by people who care to speak up so far.
There is no intention to provide a ta
The more we discuss it, the more PM becomes a focal point. I agree with
Greg Schafer in that the actual choice of PM is a user's choice in the
end and shouldn't matter.
About all we should attempt to do is inform the user of all the main
stream and (perhaps) some of the not-so-mainstream option
toolchain components (most notably, glibc)
> painlessly
> [ ] Ability to revert mistakes easily and quickly by installing an old
> binary package
> [ ] Ability to compile once, deploy on many macines
> [ ] Scripting the build
>
> I will ignore the future LFS advice on package manag
Do you have a running tally on this thread so-far, Alexander? I know,
some 30 replies hardly counts as a cross-section of the LFS community,
but at least it's a start by people who care to speak up so far.
I considered providing my own results but it seems I put an X in just
about every categor
S on more than one PC (including virtual machines)
> [X] I deviate a lot from LFS (not counting package updates as deviations)
I use DIY Linux actually and I don't deviate from it a lot.
> [X] I deviate a lot from BLFS (not counting package updates as deviations)
>
> I use t
ects
> [X] I use LFS as my primary Linux system
> [ ] I use LFS on more than one PC (including virtual machines)
> [x] I deviate a lot from LFS (not counting package updates as deviations)
> [x] I deviate a lot from BLFS (not counting package updates as deviations)
>
> I use the
TheOldFellow wrote:
> On Tue, 04 Mar 2008 08:30:50 +1100
> Greg Schafer <[EMAIL PROTECTED]> wrote:
> Having said that, I believe
>> PM should be a personal thing, which is why I would never advise anyone
>> "you must XYZ as your PM". ie: I would never select a default PM for LFS.
>
> On the other
1 - 100 of 173 matches
Mail list logo
