Next problem, rpm organization
I'm thinking of rearranging the spec file to make these packages:
hotplug-core
hotplug-utils
The -core package contains the existing scripts and makes up the directory structure on the target system. This includes the basic hotplug script and the rc files needed to enable the system.
The -utils package contains utility programs that specific devices might want or need. This is where the fxload program would go. Only packages that needed a utility program in here would depend on this package.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Stephen Williams
I'm thinking of rearranging the spec file to make these packages:
hotplug-core
hotplug-utils
Quoted 8 lines
The -core package contains the existing scripts and makes up the directory structure on the target system. This includes the basic hotplug script and the rc files needed to enable the system.
The -utils package contains utility programs that specific devices might want or need. This is where the fxload program would go. Only packages that needed a utility program in here would depend on this package.
But the fxload isn't dependent on the hotplug-core, now is it?
As for the directory structure questions, I say just have a fxload subdirectory from the main root. And move the Makefile that builds everything to the main directory also. That way we aren't dependent on any directory layout specifics (I think debian's directory tree is different from Red Hat's in some specific places.) Then the .rpm or .deb file can build their packages to suit their layouts.
Just my 2 cents.
thanks,
greg k-h
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 1 line · [email protected] said:
But the fxload isn't dependent on the hotplug-core, now is it?
Correct, and it will install even if hotplug-core isn't installed. There is precedent for this relationship, for example the nfs-server and nfs-clients packages, which are mutually independent, though from the same source tree.
Quoted 3 lines · [email protected] said:
As for the directory structure questions, I say just have a fxload subdirectory from the main root. And move the
Makefilethat builds everything to the main directory also.
So I should create admin/fxload, and admin/Makefile, and encourage new programs be added in directories under admin/<foo> and into the admin/Makefile makefile. I can modify the spec file and install targets apropriately.
I can do that, if you would like. My initial proposal was designed to minimize the impact.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Stephen Williams
Quoted 1 line · [email protected] said:
But the fxload isn't dependent on the hotplug-core, now is it?
Correct, and it will install even if hotplug-core isn't installed. There is precedent for this relationship, for example the nfs-server and nfs-clients packages, which are mutually independent, though from the same source tree.
True, ok, I'm convinced :)
Quoted 7 lines
So I should create admin/fxload, and admin/Makefile, and encourage new programs be added in directories under admin/<foo> and into the admin/Makefile makefile. I can modify the spec file and install targets apropriately.
I can do that, if you would like. My initial proposal was designed to minimize the impact.
I like this, and don't mind moving things around a bit if it makes sense. If David agrees I say do it.
thanks,
greg k-h
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines
I'm thinking of rearranging the spec file to make these packages:
hotplug-core
hotplug-utilsThe -core package contains the existing scripts and makes up the directory structure on the target system. This includes the basic hotplug script and the rc files needed to enable the system.
Two packages, one being more or less the current hotplug package, seems about right to me.
Quoted 4 lines
The -utils package contains utility programs that specific devices might want or need. This is where the fxload program would go. Only packages that needed a utility program in here would depend on this package.
Where would you put stuff like "usbmodules", used for "cold-plugging"?
I guess I'm thinking that "fxload" is more like "usbutils", and maybe what should happen is that the hotplug project should host that and add "fxload" to it.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines
Quoted 7 lines
So I should create admin/fxload, and admin/Makefile, and encourage new programs be added in directories under admin/<foo> and into the admin/Makefile makefile. I can modify the spec file and install targets apropriately.
I can do that, if you would like. My initial proposal was designed to minimize the impact.
I like this, and don't mind moving things around a bit if it makes sense. If David agrees I say do it.
My main concern with directory layout is not to invent another policy for each tool that comes by ... try to pick something and stick with it! I'm content to have someone else choose that policy; admin/foo is OK.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · [email protected] said:
I guess I'm thinking that "fxload" is more like "usbutils", and maybe what should happen is that the hotplug project should host that and add "fxload" to it.
Gosh darn it, every time you think you've got a plan, someone else comes up with a worthy consideration.
I'm assuming you meant "usbutils" by Thomas Sailor? Yeah, I suppose it is possible for the hotplug source tree to fold the lot in and make a consistent, larger set of tools.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
Quoted 3 lines
I guess I'm thinking that "fxload" is more like "usbutils", and maybe what should happen is that the hotplug project should host that and add "fxload" to it.
Gosh darn it, every time you think you've got a plan, someone else comes up with a worthy consideration.
:)
Quoted 3 lines
I'm assuming you meant "usbutils" by Thomas Sailor? Yeah, I suppose it is possible for the hotplug source tree to fold the lot in and make a consistent, larger set of tools.
Particularly since Thomas' utilities haven't incorporated patches for some time, and the most current stuff is linked to from the hotplug website ... there's even a spec file all set up!
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines
Gosh darn it, every time you think you've got a plan, someone else comes up with a worthy consideration.
Quoted 3 lines · [email protected] said:
Particularly since Thomas' utilities haven't incorporated patches for some time, and the most current stuff is linked to from the hotplug website
OK, this is what I will do.
I will go ahead and create the admin/fxload directory and put the source in there. I'll add to the admin/Makefile targets to build and install things, and I'll update the .spec file to match. This will not preclude sucking the usbutils utilities into this structure, possibly autoconfig'ing the tree as we go.
Simple, uniform, and compatible.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · David Brownell
Particularly since Thomas' utilities haven't incorporated patches for some time, and the most current stuff is linked to from the hotplug website ... there's even a spec file all set up!
That's not true, I have incorporated all patches I'm aware of into usb.in.tum.de CVS.
Tom
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
I think I see what's going on ... the last released version doesn't match CVS, and I never got any responses from you for the last sets of patches I sent. Some of them got in, attributed to other folk (like GregKH for my man page updates).
Net result is that the "usbmodules" in your release doesn't work with "shipping" 2.4 kernels/modutils. So it doesn't help much for anyone wanting hotplug support ...
The most up-to-date release I know about is linked from:
http://linux-hotplug.sourceforge.net/?selected=setup
That's got RPMs (more current spec file, installs in a better place...) and various patches that you haven't released. I don't know if that includes _all_ those patches though. It shouldn't be too different from your CVS if you did incorporate all the patches that were sent to you.
Minor problem with usbmodules, worth fixing: it doesn't handle "# ..." style comment syntax.
- Dave
----- Original Message -----
From: "Thomas Sailer" <[email protected]>
To: "David Brownell" <[email protected]>
Cc: "Stephen Williams" <[email protected]>; <[email protected]>
Sent: Tuesday, June 12, 2001 4:14 AM
Subject: Re: Next problem, rpm organization
Quoted 10 lines
Quoted 3 lines · David Brownell
Particularly since Thomas' utilities haven't incorporated patches for some time, and the most current stuff is linked to from the hotplug website ... there's even a spec file all set up!
That's not true, I have incorporated all patches I'm aware of into usb.in.tum.de CVS.
Tom
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel