[linux-lvm] Debian packaging

[linux-lvm] Debian packaging

[Russell Coker]

I plan to take over the Debian package of lvm because the current maintainer 
hasn't fixed serious bugs for quite a while.

I have created packages for lvm 0.8.1 and lvm 0.9.  One change I think should 
be done is an option for ./configure to specify whether a shared library 
should be used or whether the programs should be statically linked.  If this 
is desired then someone please tell me which version I should create a patch 
against and I'll send it in.

Also as part of the Debian packaging I have put the following patch in to 
make it clean up all files after compiling:
diff -ruN ../LVM.orig/lvm-0.8.1.orig/Makefile.in lvm-0.8.1-0/Makefile.in
--- ../LVM.orig/lvm-0.8.1.orig/Makefile.in      Sun Nov 12 19:52:12 2000
+++ lvm-0.8.1-0/Makefile.in     Wed Dec 13 15:40:06 2000
@@ -39,4 +39,5 @@
 distclean: clean
        $(MAKE) -C tools distclean
        rm -f config.cache config.log config.status
-       rm -f Makefile make.tmpl
+       rm -f Makefile make.tmpl tools/Makefile tools/tools_and_lib.make.tmpl 
\
+              tools/lib/Makefile tools/man8/Makefile 

Also I have put in the following patch to work with the way Debian packages 
have different compile and install directories:
--- ../LVM.orig/lvm-0.8.1.orig/make.tmpl.in     Sun Nov 12 19:52:12 2000
+++ lvm-0.8.1-0/make.tmpl.in    Wed Dec 13 15:40:06 2000
@@ -35,11 +35,16 @@
 # Setup directory variables
 prefix = @prefix@
 exec_prefix = @exec_prefix@
-bindir = @bindir@
-sbindir = @sbindir@
-libdir = @libdir@
-infodir = @infodir@
-mandir = @mandir@
+bindir = ${PREFIX}@bindir@
+sbindir = ${PREFIX}@sbindir@
+libdir = ${PREFIX}@libdir@
+infodir = ${PREFIX}@infodir@
+mandir = ${PREFIX}@mandir@
+
+ifeq ($(TOP),)
+TOP := $(shell cd `for i in . .. ../..; do if [ -f $$i/LVM-HOWTO ]; then 
echo $$i; break; fi; done`; pwd)
+export TOP
+endif
 
 # helper scripts
 UNINSTALL = ${TOP}/autoconf/uninstall.pl


Also I would prefer to have the Debian packaging files in the upstream 
source.  They are about 5K of data in 11 files in a separate sub-directory.  
Please let me know if this would be desired/accepted as part of the LVM 
upstream source and I will send the relevant patch to you.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Re: [linux-lvm] Debian packaging

[Tamas Gergely]

Hi!

As I noticed the LVM utilities are placed under /usr in this LVM.DEB .

Wouldn't it be better to use '/' as root not '/usr'?
I mean, it would be better to place the utilities into /sbin instead of
/usr/sbin.

(on many systems /usr is located on an LV. But activiting/disactivating
using vgchange is impossible after unmounting /usr)

Thanks in advance,
Gergely Tamas

Re: [linux-lvm] Debian packaging

[Russell Coker]

On 2000-12-14 16:50, Tamas Gergely wrote:
>As I noticed the LVM utilities are placed under /usr in this LVM.DEB .

That's what the old package does.

>Wouldn't it be better to use '/' as root not '/usr'?

That's what my development packages (which I have shared with no-one) do.

>I mean, it would be better to place the utilities into /sbin instead of
>/usr/sbin.

Depends.  One thing I would like to do is go through the utilities and put 
things that are needed to kickstart a system or to recover a hosed system 
into /sbin .  Then things that aren't so critical to the boot process (lvmsar 
springs to mind) belong in /usr/sbin .

>(on many systems /usr is located on an LV. But activiting/disactivating
>using vgchange is impossible after unmounting /usr)

Yes.  My package will differ quite a bit from the existing Debian package.  
Also I plan to make everything use shared libraries.  ls, cp, and mv are not 
statically linked so I don't think that there is any need for statically 
linked lvm utilities.  My lvm package will be considerably smaller than the 
current one (which is necessary for boot support).

I would appreciate any suggestions on this.  Also if anyone is brave and 
wants to beta-test my packages then I would be very interested in hearing 
from them.

One other thing, it seems that the protocol is changing often.  How should 
this be managed in Debian packages?  I had thought of doing lvm22 and lvm24 
as package names for the 2.2.x and 2.4.x kernels, but now I get the 
impression that the interfaces will change between those series.  Also 0.8.1, 
0.9, and 0.8i all seem to have different protocol versions.

This has two problems, one is that users won't know which one they need, the 
other is how to manage an upgrade of a kernel!

I was thinking that perhaps what I should do is have /sbin/lvm-ver and 
/lib/lvm-ver directories where "ver" is the version of LVM in question.  Then 
at boot time there is a script that determines the version of LVM in the 
kernel and creates sym-links from /sbin and /lib to the correct directories.  
This is REALLY ugly, but it enables a user to cleanly have a machine that can 
be booted on 2.2 or 2.4 kernel and just work each time you boot it.

Any better suggestions?

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Re: [linux-lvm] Debian packaging

[Ragnar Kjørstad]

On Thu, Dec 14, 2000 at 05:22:17PM +0100, Russell Coker wrote:
> I was thinking that perhaps what I should do is have /sbin/lvm-ver and 
> /lib/lvm-ver directories where "ver" is the version of LVM in question.  Then 
> at boot time there is a script that determines the version of LVM in the 
> kernel and creates sym-links from /sbin and /lib to the correct directories.  
> This is REALLY ugly, but it enables a user to cleanly have a machine that can 
> be booted on 2.2 or 2.4 kernel and just work each time you boot it.
> 
> Any better suggestions?

What about putting shell-scripts in /sbin, and have theese scripts
execute the real programs?

It adds a little more overhead to all lvm-commands, but you avoid the
need for setting anything up at boot-time.


-- 
Ragnar Kj�rstad

Re: [linux-lvm] Debian packaging

[Claudio Matsuoka]

On Sun, 17 Dec 2000, Ragnar Kjørstad wrote:

> > I was thinking that perhaps what I should do is have /sbin/lvm-ver and 
> > /lib/lvm-ver directories where "ver" is the version of LVM in question.  Then 
> > at boot time there is a script that determines the version of LVM in the 
> > kernel and creates sym-links from /sbin and /lib to the correct directories.  
> > This is REALLY ugly, but it enables a user to cleanly have a machine that can 
> > be booted on 2.2 or 2.4 kernel and just work each time you boot it.
>
> What about putting shell-scripts in /sbin, and have theese scripts
> execute the real programs?


Placing a single script (symlinked from several names) that detects the
protocol version and executes $0 in /lib/lvm-ver could make maintenance
easier.

Re: [linux-lvm] Debian packaging

[Luca Berra]

On Thu, Dec 14, 2000 at 05:22:17PM +0100, Russell Coker wrote:
> Yes.  My package will differ quite a bit from the existing Debian package.  
> Also I plan to make everything use shared libraries.  ls, cp, and mv are not 
> statically linked so I don't think that there is any need for statically 
> linked lvm utilities.  My lvm package will be considerably smaller than the 
> current one (which is necessary for boot support).

this is something i could never understand in current linux distros :(

> One other thing, it seems that the protocol is changing often.  How should 
> this be managed in Debian packages?  I had thought of doing lvm22 and lvm24 
> as package names for the 2.2.x and 2.4.x kernels, but now I get the 
> impression that the interfaces will change between those series.  Also 0.8.1, 
> 0.9, and 0.8i all seem to have different protocol versions.

The protocol is kernel independent, the protocol changes between lvm releases

> This has two problems, one is that users won't know which one they need, the 
> other is how to manage an upgrade of a kernel!

if luser has 2.2 kernel she must have patched it to support LVM so she probably knows
what she's doing.

> I was thinking that perhaps what I should do is have /sbin/lvm-ver and 
> /lib/lvm-ver directories where "ver" is the version of LVM in question.  Then 
> at boot time there is a script that determines the version of LVM in the 
> kernel and creates sym-links from /sbin and /lib to the correct directories.  
> This is REALLY ugly, but it enables a user to cleanly have a machine that can 
> be booted on 2.2 or 2.4 kernel and just work each time you boot it.
> 
> Any better suggestions?
you should look at the wrapper i posted some days ago.

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

Re: [linux-lvm] Debian packaging

[Andreas Dilger]

Russel Coker writes:
> >I mean, it would be better to place the utilities into /sbin instead of
> >/usr/sbin.
> 
> Depends.  One thing I would like to do is go through the utilities and put 
> things that are needed to kickstart a system or to recover a hosed system 
> into /sbin .  Then things that aren't so critical to the boot process (lvmsar 
> springs to mind) belong in /usr/sbin .

As with other people, I think it would be best to place the LVM user utils
into /sbin/lvm-<IOP version>.  However, I think it is NOT a good idea to
put wrapper scripts in /sbin.  Instead, simply set the path at boot time
(/etc/rc.d/rc.sysinit, and for root) to include the correct directory if
it exists.

Basically, I'm going to write a 5 line program that only gets the LVM IO
protocol version and spits it to stdout, ala:

IOP=`lvmiopversion`	# only this command will be directly in /sbin

[ "$IOP" ] && PATH=/sbin/lvm-$IOP:$PATH

so if the version-specific LVM user tools directory doesn't exist, we will
still look for old tools in /sbin.  Never reference LVM tools by absolute path.
It would be nice if the stock LVM configuration also started doing this,
but it will be a minor change to the Makefile.

> Yes.  My package will differ quite a bit from the existing Debian package.  
> Also I plan to make everything use shared libraries.  ls, cp, and mv are not 
> statically linked so I don't think that there is any need for statically 
> linked lvm utilities.  My lvm package will be considerably smaller than the 
> current one (which is necessary for boot support).

Probably not a bad idea.

> One other thing, it seems that the protocol is changing often.  How should 
> this be managed in Debian packages?  I had thought of doing lvm22 and lvm24 
> as package names for the 2.2.x and 2.4.x kernels, but now I get the 
> impression that the interfaces will change between those series.  Also 0.8.1, 
> 0.9, and 0.8i all seem to have different protocol versions.

You should name packages by the IOP version.  It will be a bit of a challenge
as LVM 0.8i was IOP 5, LVM 0.8final was IOP 6, and LVM 0.9 is IOP 10.  Maybe
Heinz can number future LVM releases by their IOP version?

> I was thinking that perhaps what I should do is have /sbin/lvm-ver and 
> /lib/lvm-ver directories where "ver" is the version of LVM in question.
> Then at boot time there is a script that determines the version of LVM in the 
> kernel and creates sym-links from /sbin and /lib to the correct directories.  

Think PATH - this is really easy, and shells already support it.  No more
work to be done, and it's not ugly.  The IOP version will probably never
change within a boot (unless LVM is a module and it gets upgraded without
upgrading the kernel - unlikely).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Debian packaging

[Claudio Matsuoka]

On Sun, 17 Dec 2000, Andreas Dilger wrote:

> As with other people, I think it would be best to place the LVM user utils
> into /sbin/lvm-<IOP version>.  However, I think it is NOT a good idea to
> put wrapper scripts in /sbin.  Instead, simply set the path at boot time
> (/etc/rc.d/rc.sysinit, and for root) to include the correct directory if
> it exists.

This approach is indeed much cleaner, but my concern is that it will make
all scripts that use the full path for the tools (e.g. /sbin/vgscan, or
[ -x /sbin/vgscan ]) fail.

I'm following Russel's idea in a experimental RPM package for Conectiva,
splitting the "lvm" package into lvm-base with the common files (requiring
a virtual lvm-tools) and lvm-iopXX (each IOP version providing lvm-tools).
This package layout should be good for apt-get as well. I'll make the SRPM
available as soon as I finish it, if anyone wants to have a look.


claudio

Re: [linux-lvm] Debian packaging

[Fionn Behrens]

Hi Andreas Dilger,

on 17-Dec-2000 you wrote:
 
>> I was thinking that perhaps what I should do is have /sbin/lvm-ver and 
>> /lib/lvm-ver directories where "ver" is the version of LVM in question.
>> Then at boot time there is a script that determines the version of LVM in
>> the 
>> kernel and creates sym-links from /sbin and /lib to the correct
>> directories.  
> 
> Think PATH - this is really easy, and shells already support it.  No more
> work to be done, and it's not ugly.  The IOP version will probably never
> change within a boot (unless LVM is a module and it gets upgraded without
> upgrading the kernel - unlikely).

Shouldnt the debian alternatives mechanism (see "man 8 update-alternatives")
be most appropriate for this task?

Regards,
        Fionn

Re: [linux-lvm] Debian packaging

[Andreas Dilger]

Fionn writes:
> > Think PATH - this is really easy, and shells already support it.  No more
> > work to be done, and it's not ugly.  The IOP version will probably never
> > change within a boot (unless LVM is a module and it gets upgraded without
> > upgrading the kernel - unlikely).
> 
> Shouldnt the debian alternatives mechanism (see "man 8 update-alternatives")
> be most appropriate for this task?

No, because you can have multiple kernels installed, and the LVM IOP may
change depending on the LVM version, even within a single kernel release
(i.e. 2.2 or 2.4).  It would be nice (but more complex) if the LVM user
tools could handle multiple IOP versions, but they don't.  Also, the
update-alternatives functionality is only available on Debian, so we
would still need another mechanism on RPM-based systems, and it may
as well be uniform across all systems.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Debian packaging

[Ulf Bartelt]

Hi!

> No, because you can have multiple kernels installed, and the LVM IOP may
> change depending on the LVM version, even within a single kernel release
> (i.e. 2.2 or 2.4).  It would be nice (but more complex) if the LVM user
> tools could handle multiple IOP versions, but they don't.  Also, the
> update-alternatives functionality is only available on Debian, so we
> would still need another mechanism on RPM-based systems, and it may
> as well be uniform across all systems.

If I had to solve this I'd try to

* give the lvm lib a name like liblvm-IOPNUMBER.so

* put all the lvm tools in a library liblvmtools-IOPNUMBER.so

* and the "real" tool binaries would only be a short program asking for
the IOPNUMBER, dynloading the the libtools-IOPNUMBER.so and passing all
args to the real tool inside that lib...

Strange idea?

Bye!
	Ulf.

Re: [linux-lvm] Debian packaging

[Claudio Matsuoka]

On Tue, 19 Dec 2000, Andreas Dilger wrote:

> No, because you can have multiple kernels installed, and the LVM IOP may
> change depending on the LVM version, even within a single kernel release
> (i.e. 2.2 or 2.4).  It would be nice (but more complex) if the LVM user
> tools could handle multiple IOP versions, but they don't.  Also, the
> update-alternatives functionality is only available on Debian, so we
> would still need another mechanism on RPM-based systems, and it may
> as well be uniform across all systems.

Ok, experimental lvm-base, lvm-iop6 and lvm-iop10 RPM packages available
at http://distro.conectiva.com.br/experimental/lvm. They certainly need
improvements, but I'm able to transparently switch back and forth between
IOP 6 and IOP 10.

To get the packages using APT, add the following lines to sources.list:

rpm http://distro.conectiva.com.br/experimental lvm/conectiva main
rpm-src http://distro.conectiva.com.br/experimental lvm/conectiva main


claudio

Re: [linux-lvm] Debian packaging

[Russell Coker]

> > Think PATH - this is really easy, and shells already support it.  No more
> > work to be done, and it's not ugly.  The IOP version will probably never
> > change within a boot (unless LVM is a module and it gets upgraded without
> > upgrading the kernel - unlikely).
>
> Shouldnt the debian alternatives mechanism (see "man 8
> update-alternatives") be most appropriate for this task?

Update-alternatives doesn't work when the file-system in question is mounted 
read-only.  Also it's not really designed to be run at every boot.

PATH is a bad idea IMHO.  It is set in too many places and has too many 
possibilities to be stuffed up.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Re: [linux-lvm] Debian packaging

[lewis]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

On Thu, Dec 21, 2000 at 08:53:29AM +1100, Russell Coker wrote:
> > > Think PATH - this is really easy, and shells already support it.  No more
> > > work to be done, and it's not ugly.  The IOP version will probably never
> > > change within a boot (unless LVM is a module and it gets upgraded without
> > > upgrading the kernel - unlikely).
> >
> > Shouldnt the debian alternatives mechanism (see "man 8
> > update-alternatives") be most appropriate for this task?
> 
> Update-alternatives doesn't work when the file-system in question is mounted 
> read-only.  Also it's not really designed to be run at every boot.
> 
> PATH is a bad idea IMHO.  It is set in too many places and has too many 
> possibilities to be stuffed up.

Doesn't the liblvm.so versioning in the cvs code take care of this problem?

-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-379-3951
1313 5th St SE, Suite 111              Fax:    612-379-3952
Minneapolis, MN 55414                  E-Mail: lewis@sistina.com
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)
-----Begin Obligatory Humorous Quote----------------------------------------
No-one suspects the butterfly!
-----End Obligatory Humorous Quote------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] Debian packaging

[Andreas Dilger]

AJ writes:
> > Update-alternatives doesn't work when the file-system in question is
> > mounted  read-only.  Also it's not really designed to be run at every boot.
> > 
> > PATH is a bad idea IMHO.  It is set in too many places and has too many 
> > possibilities to be stuffed up.
> 
> Doesn't the liblvm.so versioning in the cvs code take care of this problem?

Only if the LVM user tools are dynamically linked (old ones won't be),
and assuming that the "tools" part of the commands don't change, only
the "lib" part.  I'm not sure that the latter will be true.  Looking at
the user commands, for example the LVM_CHECK_IOP macro hard-codes the
LVM_LIB_IOP_VERSION into the "tool" part of the binary, rather than
doing the checking inside the library (which is really what should do
all the interfacing with the kernel).

Until this is fixed (it may be harder than it seems, and may make for lots
of restrictions on what can be changed in the user commands), the only
thing that the liblvm.so versioning allows is for multiple dynamically
linked user tools to be installed (iff they are in different directories).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Debian packaging

[HIBINO Kei]

At Thu, 14 Dec 2000 16:50:41 +0100 (CET),
Tamas Gergely wrote:

> As I noticed the LVM utilities are placed under /usr in this LVM.DEB .
> 
> Wouldn't it be better to use '/' as root not '/usr'?
> I mean, it would be better to place the utilities into /sbin instead of
> /usr/sbin.
> 
> (on many systems /usr is located on an LV. But activiting/disactivating
> using vgchange is impossible after unmounting /usr)

I fixed the above and some problems of pacakges placed under
'ftp://ftp.sistina.com/pub/LVM/0.9/binaries/debian/'.

I put this fixed pacakge under
'http://www.asahi-net.or.jp/~ex8k-hbn/deb/lvm/'.

-- lvm_0.9-2.1 --
  * Fix pv_get_size.		(for md device.)
  * Fix vg_read_from_pv.	(for md device.)
  * Fix pv_read_uuidlist.	(for md device.)
  * Fix install directories.	(from /usr/sbin to /sbin)
  * Set soname to liblvm.so.
  * Add 'liblvm-dev' package.
  * Add some default configuration files.
--             --

This package is working well at my mirroring device.


pear:~# pvdisplay /dev/md1
--- Physical volume ---
PV Name               /dev/md1
VG Name               dev1_vg
PV Size               36.45 GB / NOT usable 2.81 MB [LVM: 157 KB]
PV#                   1
PV Status             available
Allocatable           yes
Cur LV                5
PE Size (KByte)       4096
Total PE              9330
Free PE               3186
Allocated PE          6144
PV UUID               0lnZ0l-ZmHh-jY0S-lT4t-1Ig9-fuGw-BviVvq


pear:~# cat /proc/mdstat 
Personalities : [raid0] [raid1] 
read_ahead 1024 sectors
md1 : active raid1 hdg4[1] hde4[0] 38218560 blocks [2/2] [UU]
md0 : active raid0 hdg3[1] hde3[0] 1027968 blocks 32k chunks
unused devices: <none>
pear:~# mount
/dev/hde1 on / type ext2 (rw,errors=remount-ro,errors=remount-ro)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/md0 on /tmp type ext2 (rw)
/dev/dev1_vg/var_lv on /var type ext2 (rw)
/dev/dev1_vg/usr_lv on /usr type ext2 (rw)
/dev/dev1_vg/export_lv on /export type ext2 (rw)
/dev/dev1_vg/home_lv on /home type ext2 (rw)
/dev/dev1_vg/local_lv on /usr/local type ext2 (rw)
            .
            .
            .

Re: [linux-lvm] Debian packaging

[Gergely Tamas]

Hi!

> I fixed the above and some problems of pacakges placed under
> 'ftp://ftp.sistina.com/pub/LVM/0.9/binaries/debian/'.
>
> I put this fixed pacakge under
> 'http://www.asahi-net.or.jp/~ex8k-hbn/deb/lvm/'.

Good work.

But here are some remarks to your /etc/init.d/lvm script ...

1]----
if [ ! -f /proc/lvm ]; then
	if [ ! -f /lib/modules/`uname -r`/block/lvm.o -a ! -f /lib/modules/`uname -r`/block/lvm-mod.o ]; then
		exit 0
	fi
fi
------

What if somebody compiled lvm into the kernel, not as a module? This
script doesn't work. :(

2]----
case "$1" in
	start|"")
		echo "Setting up LVM Volume Groups..."
		#/sbin/vgscan
		/sbin/vgchange -a y
		;;
------

Why did you use 'start|""' above? If run without parameters, it should
simply display a usage help.

Thanks,
Gergely

Re: [linux-lvm] Debian packaging

[Ragnar Kjørstad]

On Fri, Dec 15, 2000 at 06:58:20PM +0100, Gergely Tamas wrote:
> > 'http://www.asahi-net.or.jp/~ex8k-hbn/deb/lvm/'.
> 
> Good work.
> 
> But here are some remarks to your /etc/init.d/lvm script ...
> 
> 1]----
> if [ ! -f /proc/lvm ]; then
> 	if [ ! -f /lib/modules/`uname -r`/block/lvm.o -a ! -f /lib/modules/`uname -r`/block/lvm-mod.o ]; then
> 		exit 0
> 	fi
> fi
> ------
> 
> What if somebody compiled lvm into the kernel, not as a module? This
> script doesn't work. :(

If lvm was compiled into the kernel /proc/lvm will exist, right?


-- 
Ragnar Kj�rstad

Re: [linux-lvm] Debian packaging

[Jay Weber]

Does /proc/lvm exist if you turn off the LVM proc reporting flag?

On Fri, 15 Dec 2000, [iso-8859-1] Ragnar Kjørstad wrote:

> On Fri, Dec 15, 2000 at 06:58:20PM +0100, Gergely Tamas wrote:
> > > 'http://www.asahi-net.or.jp/~ex8k-hbn/deb/lvm/'.
> > 
> > Good work.
> > 
> > But here are some remarks to your /etc/init.d/lvm script ...
> > 
> > 1]----
> > if [ ! -f /proc/lvm ]; then
> > 	if [ ! -f /lib/modules/`uname -r`/block/lvm.o -a ! -f /lib/modules/`uname -r`/block/lvm-mod.o ]; then
> > 		exit 0
> > 	fi
> > fi
> > ------
> > 
> > What if somebody compiled lvm into the kernel, not as a module? This
> > script doesn't work. :(
> 
> If lvm was compiled into the kernel /proc/lvm will exist, right?
> 
> 
> -- 
> Ragnar Kjørstad
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> 

Re: [linux-lvm] Debian packaging

[Gergely Tamas]

Hi!

> If lvm was compiled into the kernel /proc/lvm will exist, right?
Yes, e.g. this could be used to detect compiled-in lvm.

Gergely

Re: [linux-lvm] Debian packaging

[lewis]

[-- Attachment #1: Type: text/plain, Size: 3861 bytes --]

On Wed, Dec 13, 2000 at 09:15:22PM +0100, Russell Coker wrote:
> I plan to take over the Debian package of lvm because the current maintainer 
> hasn't fixed serious bugs for quite a while.

A couple of questions.  Have you tried contacting Tom Lees <tal26@cam.ac.uk>?  I have talked to him and he is working on LVM 0.9 packages for sure.  Has this transfer of maintainers been approved by the powers that be at Debian yet?

> I have created packages for lvm 0.8.1 and lvm 0.9.  One change I think should 
> be done is an option for ./configure to specify whether a shared library 
> should be used or whether the programs should be statically linked.  If this 
> is desired then someone please tell me which version I should create a patch 
> against and I'll send it in.

Since the configure.in scripts are essentially the same, you can just submit a
patch to one or the other to the lvm-devel list and we'll get it in on the
next release.  I am the one responsible for the conversion of LKM to the autoconf system, so I'd be interested to see how you intend to accomplish this.

> Also as part of the Debian packaging I have put the following patch in to 
> make it clean up all files after compiling:
> diff -ruN ../LVM.orig/lvm-0.8.1.orig/Makefile.in lvm-0.8.1-0/Makefile.in
> --- ../LVM.orig/lvm-0.8.1.orig/Makefile.in      Sun Nov 12 19:52:12 2000
> +++ lvm-0.8.1-0/Makefile.in     Wed Dec 13 15:40:06 2000
> @@ -39,4 +39,5 @@
>  distclean: clean
>         $(MAKE) -C tools distclean
>         rm -f config.cache config.log config.status
> -       rm -f Makefile make.tmpl
> +       rm -f Makefile make.tmpl tools/Makefile tools/tools_and_lib.make.tmpl 
> \
> +              tools/lib/Makefile tools/man8/Makefile 
> 
> Also I have put in the following patch to work with the way Debian packages 
> have different compile and install directories:
> --- ../LVM.orig/lvm-0.8.1.orig/make.tmpl.in     Sun Nov 12 19:52:12 2000
> +++ lvm-0.8.1-0/make.tmpl.in    Wed Dec 13 15:40:06 2000
> @@ -35,11 +35,16 @@
>  # Setup directory variables
>  prefix = @prefix@
>  exec_prefix = @exec_prefix@
> -bindir = @bindir@
> -sbindir = @sbindir@
> -libdir = @libdir@
> -infodir = @infodir@
> -mandir = @mandir@
> +bindir = ${PREFIX}@bindir@
> +sbindir = ${PREFIX}@sbindir@
> +libdir = ${PREFIX}@libdir@
> +infodir = ${PREFIX}@infodir@
> +mandir = ${PREFIX}@mandir@
> +
> +ifeq ($(TOP),)
> +TOP := $(shell cd `for i in . .. ../..; do if [ -f $$i/LVM-HOWTO ]; then 
> echo $$i; break; fi; done`; pwd)
> +export TOP
> +endif
>  
>  # helper scripts
>  UNINSTALL = ${TOP}/autoconf/uninstall.pl

Are you saying you want this patch applied to the upstream source?  That
really doesn't make much sense to me.  The Makefile.in patch is completely
unnecessary because the subdirectories Makefile.in files handle those
cleanups.  And it doesn't make any sense to me to put the ${PREFIX} stuff in
the upstream version, as it is not necessary.  That is what the
package.diff.gz file is created for when you build Debian packages.  That way
when you make a new version, the changes you made to the source are applied to
the new code.

> Also I would prefer to have the Debian packaging files in the upstream 
> source.  They are about 5K of data in 11 files in a separate sub-directory.  
> Please let me know if this would be desired/accepted as part of the LVM 
> upstream source and I will send the relevant patch to you.

One question.  Why?  Seems completely unnecessary to me.

Regards,
-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-379-3951
1313 5th St SE, Suite 111              Fax:    612-379-3952
Minneapolis, MN 55414                  E-Mail: lewis@sistina.com
Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648

No-one suspects the butterfly!

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] Debian packaging

[Russell Coker]

On 2000-12-14 17:46, lewis@sistina.com wrote:
>>On Wed, Dec 13, 2000 at 09:15:22PM +0100, Russell Coker wrote:
>> I plan to take over the Debian package of lvm because the current
>> maintainer hasn't fixed serious bugs for quite a while.
>
>A couple of questions.  Have you tried contacting Tom Lees
> <tal26@cam.ac.uk>?  I have talked to him and he is working on LVM 0.9
> packages for sure.  Has this transfer of maintainers been approved by the
> powers that be at Debian yet?

I have sent him email at his tom@debian.org address.

If you don't reply to email sent to the package maintainer address and don't 
fix high-priority bugs in your packages then your packages can be NMU'd 
without any issue.  After an NMU if there is still no response then they are 
up for grabs.

If he doesn't want me to take over the package then he will have to reply to 
my email.

>> I have created packages for lvm 0.8.1 and lvm 0.9.  One change I think
>> should be done is an option for ./configure to specify whether a shared
>> library should be used or whether the programs should be statically
>> linked.  If this is desired then someone please tell me which version I
>> should create a patch against and I'll send it in.
>
>Since the configure.in scripts are essentially the same, you can just submit
> a patch to one or the other to the lvm-devel list and we'll get it in on
> the next release.  I am the one responsible for the conversion of LKM to
> the autoconf system, so I'd be interested to see how you intend to
> accomplish this.

LKM?

>Are you saying you want this patch applied to the upstream source?  That
>really doesn't make much sense to me.  The Makefile.in patch is completely
>unnecessary because the subdirectories Makefile.in files handle those

Right.  At the time I wrote it I obviously hadn't looked at the code enough.  
It had seemed not to do what I wanted so I patched it.

>cleanups.  And it doesn't make any sense to me to put the ${PREFIX} stuff in
>the upstream version, as it is not necessary.  That is what the

You're right.  It's better to set prefix=`pwd`/debian/tmp/ at install time.

>> Also I would prefer to have the Debian packaging files in the upstream
>> source.  They are about 5K of data in 11 files in a separate
>> sub-directory. Please let me know if this would be desired/accepted as
>> part of the LVM upstream source and I will send the relevant patch to you.
>
>One question.  Why?  Seems completely unnecessary to me.

It makes things easier for people doing other distributions amoung other 
things.  If you had a Red Hat spec file in there then it would have made 
things a bit easier for me (I could probably find one on the net somewhere 
but then there's issues of whether it matches the source I've got etc).
Also if someone submits a patch for lvm then they would (hopefully) also 
patch the Debian setup in a matching fashion thus saving duplication of 
effort.
Debian packaging files in the CVS works well for KDE...

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Re: [linux-lvm] Debian packaging

[lewis]

[-- Attachment #1: Type: text/plain, Size: 2551 bytes --]

On Fri, Dec 15, 2000 at 07:51:10AM +0100, Russell Coker wrote:
> If you don't reply to email sent to the package maintainer address and don't 
> fix high-priority bugs in your packages then your packages can be NMU'd 
> without any issue.  After an NMU if there is still no response then they are 
> up for grabs.
>
> If he doesn't want me to take over the package then he will have to reply to 
> my email.

Sounds good to me.  I want those packages updated and working too.

> >Since the configure.in scripts are essentially the same, you can just submit
> > a patch to one or the other to the lvm-devel list and we'll get it in on
> > the next release.  I am the one responsible for the conversion of LKM to
> > the autoconf system, so I'd be interested to see how you intend to
> > accomplish this.
> 
> LKM?

Oops...that's supposed to be LVM.

> >> Also I would prefer to have the Debian packaging files in the upstream
> >> source.  They are about 5K of data in 11 files in a separate
> >> sub-directory. Please let me know if this would be desired/accepted as
> >> part of the LVM upstream source and I will send the relevant patch to you.
> >
> >One question.  Why?  Seems completely unnecessary to me.
> 
> It makes things easier for people doing other distributions amoung other 
> things.  If you had a Red Hat spec file in there then it would have made 
> things a bit easier for me (I could probably find one on the net somewhere 
> but then there's issues of whether it matches the source I've got etc).
> Also if someone submits a patch for lvm then they would (hopefully) also 
> patch the Debian setup in a matching fashion thus saving duplication of 
> effort.
> Debian packaging files in the CVS works well for KDE...

But if you have your packaging scripts setup correctly, when an upstream
version changes, you just run uupdate -u upstream-package.tar.gz and it
updates the source and puts it into the correct tree...seems much easier to
maintain than trying to keep everything current in the CVS.  As long as you
are releasing the debian source tarball as well as the binary, this shouldn't
be an issue.

-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-379-3951
1313 5th St SE, Suite 111              Fax:    612-379-3952
Minneapolis, MN 55414                  E-Mail: lewis@sistina.com
Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648

A computer without a Microsoft operating system is like a dog without bricks
tied to its head.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] Debian packaging

[Tom Lees]

On Fri, Dec 15, 2000 at 07:51:10AM +0100, Russell Coker wrote:
> I have sent him email at his tom@debian.org address.
> 
> If you don't reply to email sent to the package maintainer address and don't 
> fix high-priority bugs in your packages then your packages can be NMU'd 
> without any issue.  After an NMU if there is still no response then they are 
> up for grabs.
> 
> If he doesn't want me to take over the package then he will have to reply to 
> my email.

I have not had much time recently (and probably won't for a bit) for LVM, so
an NMU would be quite appropriate at this stage. However, I'd like to
continue maintaining the package.

Incidentally, the main problem in packaging 0.9 has been that I've been
unable to compile the latest 2.4-test kernels with LVM support (and
therefore unable to test my packages) - otherwise, they're pretty much
ready. I'll try and get this sorted out soon.

-- 
>-Tom Lees-< 2nd yr Maths Undergrad/St John's College/University of Cambridge
       -- <Tom.Lees@bigfoot.com> <tal26@cam.ac.uk> <tom@debian.org> --

Re: [linux-lvm] Debian packaging

[Claudio Matsuoka]

On Tue, 19 Dec 2000, Andreas Dilger wrote:

> No, because you can have multiple kernels installed, and the LVM IOP may
> change depending on the LVM version, even within a single kernel release
> (i.e. 2.2 or 2.4).  It would be nice (but more complex) if the LVM user
> tools could handle multiple IOP versions, but they don't.  Also, the
> update-alternatives functionality is only available on Debian, so we
> would still need another mechanism on RPM-based systems, and it may
> as well be uniform across all systems.

Ok, experimental lvm-base, lvm-iop6 and lvm-iop10 RPM packages available
at http://distro.conectiva.com.br/experimental/lvm. They certainly need
improvements, but I'm able to transparently switch back and forth between
IOP 6 and IOP 10.

To get the packages using APT, add the following lines to sources.list:

rpm http://distro.conectiva.com.br/experimental lvm/conectiva main
rpm-src http://distro.conectiva.com.br/experimental lvm/conectiva main


claudio