Next problem, rpm organization

Next problem, rpm organization

[Stephen Williams]

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.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Next problem, rpm organization

[Greg KH]

On Sat, Jun 09, 2001 at 10:03:59AM -0700, Stephen Williams wrote:
> 
> 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.

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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Next problem, rpm organization

[Stephen Williams]

greg@kroah.com 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.

greg@kroah.com said:
> 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.

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.
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Next problem, rpm organization

[Greg KH]

On Mon, Jun 11, 2001 at 09:32:19AM -0700, Stephen Williams wrote:
> 
> greg@kroah.com 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 :)


> 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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Next problem, rpm organization

[David Brownell]

> 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.

Two packages, one being more or less the current hotplug package,
seems about right to me.


> 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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Next problem, rpm organization

[David Brownell]

> > 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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Next problem, rpm organization

[Stephen Williams]

david-b@pacbell.net 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.
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Next problem, rpm organization

[David Brownell]

> > 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.

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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Next problem, rpm organization

[Stephen Williams]

> Gosh darn it, every time you think you've got a plan, someone else
> comes up with a worthy consideration.


david-b@pacbell.net 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.
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Next problem, rpm organization

[Thomas Sailer]

David Brownell schrieb:

> 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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Next problem, rpm organization

[David Brownell]

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" <sailer@scs.ch>
To: "David Brownell" <david-b@pacbell.net>
Cc: "Stephen Williams" <steve@icarus.com>; <linux-hotplug-devel@lists.sourceforge.net>
Sent: Tuesday, June 12, 2001 4:14 AM
Subject: Re: Next problem, rpm organization


> David Brownell schrieb:
> 
> > 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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel