Joshua,
I think you summarized everything up very well. Thank you.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 5/24/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote:
> Matt,
>I did respond, but you chose to ignore it.
>
>
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2006-May/057282.html
>
No, I didn't ignore it. I saw that you said "the rules are not that
different".
Archaic wrote:
On Wed, May 24, 2006 at 08:35:09PM +0100, TheOldFellow wrote:
What I can't understand is why, when the CLFS rules have been working
for months, that LFS had to reinvent the wheel?
The LFS rules have existed since at least June 15, 2004. They predate the
CLFS book.
Yes, but
On Wed, May 24, 2006 at 08:35:09PM +0100, TheOldFellow wrote:
>
> What I can't understand is why, when the CLFS rules have been working
> for months, that LFS had to reinvent the wheel?
The LFS rules have existed since at least June 15, 2004. They predate the
CLFS book.
--
Archaic
Want cont
Matthew Burgess wrote:
Jim Gifford wrote:
Matt,
I did respond, but you chose to ignore it.
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2006-May/057282.html
No, I didn't ignore it. I saw that you said "the rules are not that
different". At which point I was left scratching
On 5/24/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
svn co http://svn.cross-lfs.org/svn/repos/udev
I checked the logs to see what's going on, but I didn't see anything.
Let me know.
It's working fine. I just did a couple test commits. I didn't know
the path and was thrown off by svn over htt
Matt,
Let us all step out of the picture and let Dan and Alex do what they
need to. We have both provided them with the current rules, svn and trac
to do with what they need. Let both LFS and CLFS drop out of the
equation for now and let that team do what they think is right.
Dan and Al
Jim Gifford wrote:
Matt,
I did respond, but you chose to ignore it.
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2006-May/057282.html
No, I didn't ignore it. I saw that you said "the rules are not that
different". At which point I was left scratching my head as to why you
Matt,
I did respond, but you chose to ignore it.
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2006-May/057282.html
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Randy McMurchy wrote:
Jim Gifford wrote these words on 05/24/06 00:19 CST:
Just let us know who you want to have full access, and those he only
need access to branches/lfs or branches/clfs. I can work offline with
you on this.
Jim, you sure went to a lot of work without even getting approval
Alexander E. Patrakov wrote:
Could you please provide https access? This would work around a broken
transparent http proxy at work.
Sure, just setup. It is using a self-signed cert so will have to accept.
hops:justin ~/tmp $ svn co https://svn.cross-lfs.org/svn/repos/udev
Error validating ser
Dan Nicholson wrote:
I've been foiled here. Is access through svnserve or http? I'm
getting blocked at svn:// and I can't find the repo with http://.
What's the name of the repo?
Dan, I just testing this command line out, let me know if it works for you
svn co http://svn.cross-lfs.org/svn/re
On 5/23/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
Ok it's now setup. http://udev.cross-lfs.org/
Alex and Dan when you sign up let me know what your usernames are so I
can give you admin access to trac and full access to the SVN.
I've been foiled here. Is access through svnserve or http? I'm
Jim Gifford wrote:
svn co http://svn.cross-lfs.org/svn/repos/udev --username {same id as
trac} --password {same password as trac}
Could you please provide https access? This would work around a broken
transparent http proxy at work.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/m
Randy McMurchy wrote:
Jim, you sure went to a lot of work without even getting approval
from the Project Leaders. Best I can tell, neither the LFS nor
BLFS project leaders have approved the plan, much less like it.
Randy,
I had to take action. I didn't include BLFS in the repo, because
On 5/24/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote these words on 05/24/06 00:19 CST:
> Just let us know who you want to have full access, and those he only
> need access to branches/lfs or branches/clfs. I can work offline with
> you on this.
Jim, you sure went to a lot of
Jim Gifford wrote these words on 05/24/06 00:19 CST:
> Just let us know who you want to have full access, and those he only
> need access to branches/lfs or branches/clfs. I can work offline with
> you on this.
Jim, you sure went to a lot of work without even getting approval
from the Project L
Jeremy Huntwork wrote:
Jim Gifford wrote:
The bottom line is if it's Alex or Dan, it needs it's own repo. With
branches for LFS and CLFS, so if we make some changes, then Alex or
Dan can merge the changes in.
On similar note I talked to DJ about this also, a separate repo for
bootscripts, wi
Access is now setup for Dan and Alex, you guys have full control. I
still have access, but you can delete it if you need to. The only other
person who has access is Justin, since he's maintainer of the hardware
for cross-lfs.org, I recommend he stays in that group for
troubleshooting for the do
Dan,
We just need someone to lay down the law between the projects. I
think your perfect for the job.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 5/23/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote:
> Ok it's now setup. http://udev.cross-lfs.org/
>
> Alex and Dan when you sign up let me know what your usernames are so I
> can give you admin access to trac and full access to the SVN.
I have registered as "[EMAIL
On 5/23/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote:
> To just make sure we all have a clear understanding.
>
> 1 - Repo will be created for Bootscripts and Udev rules
> 2 - Repo to be maintained by DJ, Alex, and Dan ( my choices). With the
> Dev Teams from BLFS, CLFS,
Alexander E. Patrakov wrote:
Jim Gifford wrote:
Ok it's now setup. http://udev.cross-lfs.org/
Alex and Dan when you sign up let me know what your usernames are so
I can give you admin access to trac and full access to the SVN.
I have registered as "[EMAIL PROTECTED]". Only then I
found that
Alexander E. Patrakov wrote:
I have registered as "[EMAIL PROTECTED]". Only then I found
that this is inconsistent with "jim". Should I re-register?
Your choice. Registered both if you want, it is all good.
Justin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxf
Jim Gifford wrote:
Ok it's now setup. http://udev.cross-lfs.org/
Alex and Dan when you sign up let me know what your usernames are so I
can give you admin access to trac and full access to the SVN.
I have registered as "[EMAIL PROTECTED]". Only then I found that
this is inconsistent with "ji
Ok it's now setup. http://udev.cross-lfs.org/
Alex and Dan when you sign up let me know what your usernames are so I
can give you admin access to trac and full access to the SVN.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See t
Jim Gifford wrote:
To just make sure we all have a clear understanding.
1 - Repo will be created for Bootscripts and Udev rules
2 - Repo to be maintained by DJ, Alex, and Dan ( my choices). With the
Dev Teams from BLFS, CLFS, and LFS.
3 - Trunk to be maintained by DJ, Alex, and Dan.
CLFS
Archaic wrote:
What stupid game? I'm pointing out that the goal of unification has
already started. The changes made thus far should not be thrown out just
because that are in the lfs repo. They should be copied into the new
repo and continued.
I'll get the repo and trac up on cross-lfs.org.
On Tue, May 23, 2006 at 06:45:38PM -0700, Jim Gifford wrote:
>
> The repo also exists in CLFS, but lets stop playing this stupid game.
> Lets get the common repo up.
What stupid game? I'm pointing out that the goal of unification has
already started. The changes made thus far should not be throw
Archaic wrote:
> On Tue, May 23, 2006 at 09:03:05PM -0400, Joe Ciccone wrote:
>
>> I think a svn repo should be added for a common set of udev rules. I
>> will be willing to go through both the lfs rules and the clfs rules,
>> find all of the common rules, and mosh them together into one common
Archaic wrote:
Replying to you and Randy, everything you described has already been
started. The repo exists now in the LFS repo. Feel free to check it out
and also to look at my email that detailed all the changes currently
made. There's more in my working copy as well. Things like adding more
s
On Tue, May 23, 2006 at 09:03:05PM -0400, Joe Ciccone wrote:
>
> I think a svn repo should be added for a common set of udev rules. I
> will be willing to go through both the lfs rules and the clfs rules,
> find all of the common rules, and mosh them together into one common
> package. I don't thi
As I've been reading this thread I noticed one common theme. control.
The main problem that I think is holding us back is that some people
don't want to give up their control over *their* udev rules.
Yes, The packages are almost identical.
Yes, It would be easy to use cat to create extra rules spe
Archaic wrote these words on 05/23/06 19:46 CST:
> But what about all the other changes? We need to discuss all differences
> and sort out which way to go every step of the way if we are going to
> produce something both books can use.
So, start the ball rolling.
As a totally neutral party to th
On Tue, May 23, 2006 at 05:29:49PM -0700, Jim Gifford wrote:
> >
> Which you pointed out, and I changed.
But what about all the other changes? We need to discuss all differences
and sort out which way to go every step of the way if we are going to
produce something both books can use.
--
Arch
Archaic wrote:
No, it wasn't logical. What was logical was to take a fresh look at
things. Udev has been a fast moving target. The rules need refreshed as
we go along. For instance, NAME="%k" is no longer needed. A second thing
was new concepts that were seemingly not present when LFS/CLFS rules
On 5/23/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
I still think, from an organisational
perspective, the rules belong in the LFS repository and that CLFS should
add to those rules, either like BLFS does via 'cat'ting to additional
files, or by providing additional rules files.
+1.
--
Tush
On 5/23/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote:
> The bottom line is if it's Alex or Dan, it needs it's own repo. With
> branches for LFS and CLFS, so if we make some changes, then Alex or Dan
> can merge the changes in.
>
> On similar note I talked to DJ about this also
On Tue, May 23, 2006 at 04:26:37PM -0700, Justin R. Knierim wrote:
>
> So why objections to merging them or even starting with the CLFS rules?
> If Alexander is to rule over them like Jeremy H and others mentioned,
> then wouldn't it be logical to start with what he already has reviewed?
No, i
Justin R. Knierim wrote:
The CLFS Udev rules were discussed in depth on the clfs-dev list,
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2006-January/055092.html
Obviously I meant lfs-dev, as the link I pasted shows. Typoed the above
sentence.
Justin
--
http://linuxfromscrat
Jim Gifford wrote:
So the bottom line is Matt, the LFS package should of never been
created. But co-operation with CLFS and a unified package could of been
born instead of us fighting. Which frankly I'm tired of it. So at this
point Matt, I think we will agree to disagree.
The CLFS Udev rules
Jim Gifford wrote:
So the bottom line is Matt, the LFS package should of never been
created. But co-operation with CLFS and a unified package could of been
born instead of us fighting.
Well, in which case, what *you* should have done is come to LFS when you
originally created the udev tarbal
Matthew Burgess wrote:
Jim Gifford wrote:
Face it LFS and CLFS both don't want to give up what we currently
have, and _/* The CLFS team is trying to compromise*/_ with this
proposal, but like normal it's the LFS way or no way.
If I knew what we were compromising on, Jim, it'd be a hell of a l
On Tue, May 23, 2006 at 04:04:31PM -0700, Jim Gifford wrote:
> >
> Because it will be one package for the entire system. No more separate
> development, no separate package. The community has wanted this for
> years, but everyone has ignored that fact.
But BLFS doesn't have rules files. They t
Jim Gifford wrote:
If we have a common repo for all projects, the unique issues that arise
from the projects can be addressed in the private repo there, under a
neutral parties control. Face it LFS and CLFS both don't want to give up
what we currently have, and _/* The CLFS team is trying to co
Archaic wrote:
I'm really not understanding why BLFS is in this proposal. They are in
addition to the rules needed by a base system (whether that base is
HLFS, CLFS, or LFS). There is nothing to be gained by putting blfs rules
in there, especially since they use cat commands to create the rules
t
Jim Gifford wrote:
Face it LFS and CLFS both don't want to give up
what we currently have, and _/* The CLFS team is trying to compromise*/_
with this proposal, but like normal it's the LFS way or no way.
If I knew what we were compromising on, Jim, it'd be a hell of a lot
easier. Tell me wha
Matthew Burgess wrote:
Jeremy Huntwork wrote:
What you have described, Matt, has been tried and has failed.
I think it's a bit too soon to be saying that it's failed. LFS has only
been using a udev-config tarball, the contents of which come from the
LFS svn repo, for a short period of time
Archaic wrote:
And BTW, Alex was consulted on all of these changes to verify their
sanity first. As for the persistence stuff, that's all his work. I just
packaged it, so what has been done so far is basically Alex's work with
me pitching in a bit. IOW, there is no need to throw the baby out with
Matthew Burgess wrote:
The major advantage to this scheme, IMO, is consistency. Everything
to do with the LFS book is in one repository. Likewise, for BLFS and
CLFS, everything concerning their books would be in their own svn
repos. If you need changes to the LFS bootscripts or rules files
On Tue, May 23, 2006 at 11:52:35PM +0100, Matthew Burgess wrote:
>
> I think it's a bit too soon to be saying that it's failed. LFS has only
> been using a udev-config tarball, the contents of which come from the
> LFS svn repo, for a short period of time.
No, not even. The repo has not been u
Matthew Burgess wrote:
Everyone? IIRC Jeremy made the suggestion, Dan agreed, now *everyone*
wants to move from a process that is well understood and appears to
work without problems to some new procedure whose benefits haven't
even been outlined?
The current process doesn't take in account
On Tue, May 23, 2006 at 10:36:07PM +0100, Matthew Burgess wrote:
>
> LFS/trunk/BOOK - LFS book, forms the base of CLFS, BLFS, etc.
> LFS/trunk/bootscripts - LFS bootscripts, forms the base on which BLFS
> and CLFS bootscripts are built on.
> LFS/trunk/udev-config - LFS udev rules, forms the base
Jeremy Huntwork wrote:
What you have described, Matt, has been tried and has failed.
I think it's a bit too soon to be saying that it's failed. LFS has only
been using a udev-config tarball, the contents of which come from the
LFS svn repo, for a short period of time.
--
http://linuxfroms
Justin R. Knierim wrote:
Jeremy Huntwork wrote:
we still need to hear Alexander's comments on it, so let's give him
the time he needs. (I think he's sleeping, atm.)
He is gone for another week at least, an exam and other things until
20060602:
http://archives.linuxfromscratch.org/mail-archi
Matthew Burgess wrote:
So, what are the drawbacks to this approach? Why won't it work?
My comments below are concerning udev *only*. As I've said, to me, the
bootscripts are a separate issue.
What you suggested is the approach that LFS has assumed up to now and
CLFS has rejected. If I'm vi
Jeremy Huntwork wrote:
we still need to hear Alexander's comments on it, so let's give him the
time he needs. (I think he's sleeping, atm.)
He is gone for another week at least, an exam and other things until
20060602:
http://archives.linuxfromscratch.org/mail-archives/livecd/2006-May/003576
Jim Gifford wrote:
Is this acceptable to all.
The bootscripts package and udev rules seem to me to be two separate
issues here, and at least until there's shown to be some benefit of
merging those two together, I'd prefer to keep them separate. So far,
most seem agreeable to making the udev
Jim Gifford wrote:
Development of the rules will need to submitted into a common svn, that
will need to be created.
I'm going to do a complete about-turn on my earlier message from
tonight. The way I see it is that the current svn layout and procedures
around them should work just fine:
L
Jim Gifford wrote these words on 05/23/06 16:07 CST:
What everyone wants is a unified package, where all the scripts for
BLFS, CLFS, and LFS are in one package. We will need to become dependent
on the this team that will be handling this package. We can have them
release a nightly tarball i
Jim Gifford wrote:
Randy,
What everyone wants is a unified package, where all the scripts for
BLFS, CLFS, and LFS are in one package.
Everyone? IIRC Jeremy made the suggestion, Dan agreed, now *everyone*
wants to move from a process that is well understood and appears to work
without pro
Randy,
What everyone wants is a unified package, where all the scripts for
BLFS, CLFS, and LFS are in one package. We will need to become dependent
on the this team that will be handling this package. We can have them
release a nightly tarball if we need to, but these are the details that
a
Jim Gifford wrote these words on 05/23/06 15:51 CST:
> Randy,
> We would have our own branches, and DJ, Alex, and Dan would control
> the releases and what is in trunk. If a release is needed, the dev teams
> would contact them with the reason for the release and they would take
> care of it
Randy,
We would have our own branches, and DJ, Alex, and Dan would control
the releases and what is in trunk. If a release is needed, the dev teams
would contact them with the reason for the release and they would take
care of it.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FA
El Martes, 23 de Mayo de 2006 22:41, Jim Gifford escribió:
> Is this acceptable to all.
Seem fine to me.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:
Jim Gifford wrote these words on 05/23/06 15:41 CST:
> Is this acceptable to all.
No. One person should not have final say on anything except an overall
project leader. For example, the entire BLFS Editing staff should have
write privileges to whatever repo will be used to create the
'production'
To just make sure we all have a clear understanding.
1 - Repo will be created for Bootscripts and Udev rules
2 - Repo to be maintained by DJ, Alex, and Dan ( my choices). With the
Dev Teams from BLFS, CLFS, and LFS.
3 - Trunk to be maintained by DJ, Alex, and Dan.
CLFS Branch to be maintai
On 5/23/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
Jim Gifford wrote:
> The bottom line is if it's Alex or Dan, it needs it's own repo. With
> branches for LFS and CLFS, so if we make some changes, then Alex or Dan
> can merge the changes in.
>
> On similar note I talked to DJ about this also
Jim Gifford wrote:
The bottom line is if it's Alex or Dan, it needs it's own repo. With
branches for LFS and CLFS, so if we make some changes, then Alex or Dan
can merge the changes in.
On similar note I talked to DJ about this also, a separate repo for
bootscripts, with the same requirements
The bottom line is if it's Alex or Dan, it needs it's own repo. With
branches for LFS and CLFS, so if we make some changes, then Alex or Dan
can merge the changes in.
On similar note I talked to DJ about this also, a separate repo for
bootscripts, with the same requirements will also need to b
Matthew Burgess wrote:
Even though I'm sure it'll differ very little (if at all) from what's
currently in LFS, sure, go ahead. Obviously we can't presume Alexander
will agree to maintain it, so if there are any other volunteers then I'm
all ears.
Well, if Alexander doesn't want the job, my s
Archaic wrote:
On Tue, May 23, 2006 at 02:21:24PM -0400, Chris Staub wrote:
I was just in the middle of writing a (somewhat longer) response that
basically said the same thing. Start the project with all the stuff
common to the LFS and CLFS rules, and go from there.
If it will allow this thi
On 5/23/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
M.Canales.es wrote:
> IMHO, the best solution is to drop both and create a separate Udev-Rules
> project managed by a neutral developer.
Heh, that's great - and I can't believe no one said it before now. And
Alexander is the perfect guy for
On Tue, May 23, 2006 at 02:21:24PM -0400, Chris Staub wrote:
>
> I was just in the middle of writing a (somewhat longer) response that
> basically said the same thing. Start the project with all the stuff
> common to the LFS and CLFS rules, and go from there.
If it will allow this thing to move
Jeremy Huntwork wrote:
Heh, that's great - and I can't believe no one said it before now. And
Alexander is the perfect guy for the job, if he's willing. If you want
neutrality and a working solution for all participants, this is the way
to go.
I was just in the middle of writing a (somewh
M.Canales.es wrote:
IMHO, the best solution is to drop both and create a separate Udev-Rules
project managed by a neutral developer.
Heh, that's great - and I can't believe no one said it before now. And
Alexander is the perfect guy for the job, if he's willing. If you want
neutrality and a w
El Martes, 23 de Mayo de 2006 19:24, Matthew Burgess escribió:
> And as much as you say you want a joint effort, you're unprepared to
> drop your package in favour of the one that LFS is using without any
> technical justification, merely saying "we had a tarball first".
IMHO, the best solution
Jim Gifford wrote:
This is my last post on this issue, like I've said I'm tired of all this
crap. This is my opinion. I know a lot of people feel the same way I do
about this, and would love to see the projects unified or at least some
type of join effort between them.
And as much as you say
On Tue, May 23, 2006 at 12:24:11AM -0700, Jim Gifford wrote:
>
> The bottom line is that LFS should of not created a new package. They
> should contacted CLFS team and worked together, which was the original
> plan way back when 2.6.15 was released.
This is apparently a misunderstanding. The p
This is my last post on this issue, like I've said I'm tired of all this
crap. This is my opinion. I know a lot of people feel the same way I do
about this, and would love to see the projects unified or at least some
type of join effort between them.
The bottom line is that LFS should of not c
On 5/22/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
We in CLFS have our udev rules. LFS has their udev rules. BLFS is
going to have their rules. Here is what I'm proposing.
Making a unified package of rules, with targets make install-lfs
and make install-clfs. Going through each of the
Archaic,
I'm tired of this constant fighting crap between the projects, you
can take credit for everything.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On Mon, May 22, 2006 at 02:26:49PM -0700, Jim Gifford wrote:
> >
> That was the point of this thread, Archaic, I said after Ryan and I
> discussed this I would post a response. So let's just forgot the whole
> thing and leave both projects separate.
Jim, you didn't post a response. You posted a
On Mon, May 22, 2006 at 02:16:42PM -0700, Justin R. Knierim wrote:
>
> WHY are you trying to discuss this privately?
Many if not most proposals are first formed off list. If a couple of
developers manage to hash something out that seems reasonable, then it
goes on list for finalization. This is n
Justin R. Knierim wrote:
Archaic wrote:
Thanks a lot for the plagarism. This is the same proposal I made to you
in a private email (and one where you never gave any comment).
Just my $0.02 but...
WHY are you trying to discuss this privately? This seems perfectly
appropriate for lfs-dev, and
Archaic wrote:
Thanks a lot for the plagarism. This is the same proposal I made to you
in a private email (and one where you never gave any comment).
Just my $0.02 but...
WHY are you trying to discuss this privately? This seems perfectly
appropriate for lfs-dev, and a good solution that most
On Mon, May 22, 2006 at 12:06:21PM -0700, Jim Gifford wrote:
>
> Making a unified package of rules, with targets make install-lfs
> and make install-clfs. Going through each of the rules and figure out
> which are common and which are specific. If that won't work, still have
> a unified pa
Jim Gifford wrote:
In CLFS we do have some additional rules, but many of them are the same.
So why don't you just drop the ones that are the same, leaving you with
just the additional rules required for CLFS?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromsc
One more point, is that both CLFS and LFS are both trying to get to a
release point in June, but to a lot of us this is an issue that needs to
be resolved.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information pag
Matthew Burgess wrote:
> Rather than creating a whole new package, why don't you just list what
> you don't like about the current LFS rules? Or has this been done
> before and I missed it?
As far as I know both sets of rules work exactly as they're intended to.
There is nothing wrong with either
Matt,
The issue is that CLFS had a udev package that was tested and now
that LFS has a udev package that has been tested, it just doesn't make
sense to have multiple packages with the same rules. In CLFS we do have
some additional rules, but many of them are the same. Numerous times
i've be
Jim Gifford wrote:
We in CLFS have our udev rules. LFS has their udev rules. BLFS is
going to have their rules. Here is what I'm proposing.
Making a unified package of rules, with targets make install-lfs
and make install-clfs.
Rather than creating a whole new package, why don't you
Jim Gifford wrote:
This is been a topic of many different discussions. A lot of people
have tried to convince both sides, but nothing has ever been settled.
It needs to be settled before this rift between projects gets any bigger.
We in CLFS have our udev rules. LFS has their udev rules. B
93 matches
Mail list logo
