Debian packaging
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:
Makefile.in Wed Dec 13 15:40:06 2000 renamed from LVM.orig/lvm-0.8.1.orig/Makefile.in Sun Nov 12 19:52:12 2000 +2 -1
@@ -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:
make.tmpl.in Wed Dec 13 15:40:06 2000 renamed from LVM.orig/lvm-0.8.1.orig/make.tmpl.in Sun Nov 12 19:52:12 2000 +8 -5
@@ -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.plAlso 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.
Signature · 4 lines
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
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
Quoted 1 line · Tamas Gergely
As I noticed the LVM utilities are placed under /usr in this LVM.DEB .
That's what the old package does.
Quoted 1 line
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.
Quoted 2 lines
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 .
Quoted 2 lines
(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?
Signature · 4 lines
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
Quoted 8 lines · Russell Coker
I was thinking that perhaps what I should do is have
/sbin/lvm-verand/lib/lvm-verdirectories 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.
Signature · 1 line
Ragnar Kj�rstad
Quoted 9 lines · Ragnar Kjørstad
Quoted 6 lines
I was thinking that perhaps what I should do is have
/sbin/lvm-verand/lib/lvm-verdirectories 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.
Quoted 5 lines · Russell Coker
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 :(
Quoted 5 lines
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
Quoted 2 lines
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.
Quoted 8 lines
I was thinking that perhaps what I should do is have
/sbin/lvm-verand/lib/lvm-verdirectories 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.
Signature · 6 lines
Luca Berra -- [email protected] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \
Quoted 7 lines · Russel Coker
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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?
Quoted 4 lines
I was thinking that perhaps what I should do is have
/sbin/lvm-verand/lib/lvm-verdirectories 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
Signature · 3 lines
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/ -- DogbertQuoted 5 lines · Andreas Dilger
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
Hi Andreas Dilger,
Quoted 11 lines · on 17-Dec-2000 you wrote:
Quoted 6 lines
I was thinking that perhaps what I should do is have
/sbin/lvm-verand/lib/lvm-verdirectories 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
Quoted 7 lines · Fionn
Quoted 4 lines
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
Signature · 3 lines
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/ -- DogbertHi!
Quoted 7 lines
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.
Quoted 7 lines · Andreas Dilger
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
Quoted 7 lines
Quoted 4 lines
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.
Signature · 4 lines
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
Quoted 5 lines · Russell Coker
Quoted 5 lines
Quoted 4 lines
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).
Quoted 8 lines
Quoted 2 lines
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?
Signature · 12 lines
AJ Lewis Sistina Software Inc. Voice: 612-379-3951 1313 5th St SE, Suite 111 Fax: 612-379-3952 Minneapolis, MN 55414 E-Mail: [email protected] 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------------------------------------------
Quoted 7 lines · AJ
Quoted 5 lines
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
Signature · 3 lines
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/ -- DogbertAt Thu, 14 Dec 2000 16:50:41 +0100 (CET),
Quoted 8 lines · Tamas Gergely
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)
.
.
.Hi!
Quoted 5 lines
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
Quoted 8 lines · Gergely Tamas
Quoted 1 line
Good work.
But here are some remarks to your
/etc/init.d/lvmscript ...1]----
if [ ! -f/proc/lvm]; then
Quoted 8 lines
if [ ! -f /lib/modules/`uname -r`/block/lvm.o -a ! -f /lib/modules/`uname -r`/block/lvm-mod.o ]; then exit 0 fifi
------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?
Signature · 1 line
Ragnar Kj�rstad
Does /proc/lvm exist if you turn off the LVM proc reporting flag?
Quoted 28 lines · On Fri, 15 Dec 2000, [iso-8859-1] Ragnar Kjørstad wrote:
Quoted 8 lines · Gergely Tamas
Quoted 1 line
Good work.
But here are some remarks to your
/etc/init.d/lvmscript ...1]----
if [ ! -f/proc/lvm]; thenQuoted 8 lines
if [ ! -f /lib/modules/`uname -r`/block/lvm.o -a ! -f /lib/modules/`uname -r`/block/lvm-mod.o ]; then exit 0 fifi
------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/lvmwill exist, right?Signature · 5 lines
Ragnar Kjørstad _______________________________________________ linux-lvm mailing list [email protected] http://lists.sistina.com/mailman/listinfo/linux-lvm
Hi!
Quoted 1 line
If lvm was compiled into the kernel
/proc/lvmwill exist, right?
Yes, e.g. this could be used to detect compiled-in lvm.
Gergely
Quoted 2 lines · 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.
A couple of questions. Have you tried contacting Tom Lees <[email protected]>? 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?
Quoted 5 lines
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.
Quoted 40 lines
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.inMakefile.in Wed Dec 13 15:40:06 2000 renamed from LVM.orig/lvm-0.8.1.orig/Makefile.in Sun Nov 12 19:52:12 2000 +1
-1@@ -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/Makefiletools/man8/MakefileAlso I have put in the following patch to work with the way Debian packages have different compile and install directories:
make.tmpl.in Wed Dec 13 15:40:06 2000 renamed from LVM.orig/lvm-0.8.1.orig/make.tmpl.in Sun Nov 12 19:52:12 2000 +10
-5@@ -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
Quoted 1 line
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.
Quoted 4 lines
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,
Signature · 7 lines
AJ Lewis Sistina Software Inc. Voice: 612-379-3951 1313 5th St SE, Suite 111 Fax: 612-379-3952 Minneapolis, MN 55414 E-Mail: [email protected] Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B 52A0 941E 1261 0029 2648 No-one suspects the butterfly!
Quoted 8 lines · On 2000-12-14 17:46, [email protected] wrote:
Quoted 3 lines · 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.
A couple of questions. Have you tried contacting Tom Lees <[email protected]>? 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 [email protected] 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.
Quoted 11 lines
Quoted 5 lines
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?
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 6 lines
Quoted 4 lines
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...
Signature · 4 lines
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
Quoted 7 lines · Russell Coker
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.
Quoted 7 lines
Quoted 5 lines
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.
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
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.
Quoted 8 lines
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.
Signature · 8 lines
AJ Lewis Sistina Software Inc. Voice: 612-379-3951 1313 5th St SE, Suite 111 Fax: 612-379-3952 Minneapolis, MN 55414 E-Mail: [email protected] 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.
Quoted 9 lines · Russell Coker
I have sent him email at his [email protected] 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.
Quoted 1 line
-Tom Lees-< 2nd yr Maths Undergrad/St John's College/University of Cambridge
-- <[email protected]> <[email protected]> <[email protected]> --