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
On Thu, May 31, 2012 at 5:40 PM, Jeremy Huntwork <
jhuntw...@lightcubesolutions.com> wrote:
> On 5/31/12 4:41 PM, James Robertson wrote:
>
> > 1. Adding PM is NOT a replacement for the books. It should also be
> > noted and clear that the purpose of this effort is not to turn (B)LFS
> > into a bi
On 5/31/12 4:41 PM, James Robertson wrote:
> I have been watching this thread and it seems to have gone a bit dormant
> so maybe now is a good time to add my thoughts. First off - Jeremy,
> your contributions to this project continue to amaze me. Keep it up buddy.
Thanks James, :)
> 1. Adding
On Sat, May 19, 2012 at 8:26 AM, Jeremy Huntwork <
jhuntw...@lightcubesolutions.com> wrote:
> I've been holding back bringing this up on-list for a while because I
> intended to do the bulk of the work and then present a working system to
> the community for comment and review. I still intend to d
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
On 05/20/2012 07:09 PM, Ken Moffat wrote:
[putolin]
> 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, t
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
On May 20, 2012, at 1:58 PM, 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
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
On 05/19/2012 09:26 AM, Jeremy Huntwork wrote:
> I've been holding back bringing this up on-list for a while because I
> intended to do the bulk of the work and then present a working system to
> the community for comment and review. I still intend to do that, but
> given some recent discussions, I
On 05/19/2012 08:26 AM, Jeremy Huntwork wrote:
> I've been holding back bringing this up on-list for a while because I
> intended to do the bulk of the work and then present a working system to
> the community for comment and review. I still intend to do that, but
> given some recent discussions, I
I've been holding back bringing this up on-list for a while because I
intended to do the bulk of the work and then present a working system to
the community for comment and review. I still intend to do that, but
given some recent discussions, I think the time is right to bring this
up and see w
35 matches
Mail list logo
