#168810 [NEW CODE REQUIRED] would be nice if pbuilder would be using some compressed loopback file image

Package:
pbuilder
Source:
pbuilder
Submitter:
Tomas Pospisek
Date:
2005-07-18 03:12:27 UTC
Severity:
wishlist
#168810#5
Date:
2002-11-12 16:54:20 UTC
From:
To:
Right now pbuilder is using a tgz. This makes changing it tiresome. It'd
be nice if pbuilder could use some compressed loopedback filesystem
image which would allow "live" changing.
*t
#168810#10
Date:
2002-11-13 15:19:58 UTC
From:
To:
Have you looked at pbuilder-uml ?


regards,
	junichi
#168810#15
Date:
2002-11-13 15:19:58 UTC
From:
To:
Have you looked at pbuilder-uml ?


regards,
	junichi
#168810#20
Date:
2002-11-13 16:02:59 UTC
From:
To:
I haven't. Looks nice. I _guess_ you'll _have_ to run it in uml then? My
problem that is that the process is slow. Using UML will make it faster
but not really fast either...

As said, I haven't looked at it yet.
*t
#168810#25
Date:
2002-11-13 16:41:04 UTC
From:
To:
What is the complaint mainly targetted at ?

slow pbuilder update ?



regards,
	junichi
#168810#30
Date:
2002-11-13 16:41:04 UTC
From:
To:
What is the complaint mainly targetted at ?

slow pbuilder update ?



regards,
	junichi
#168810#35
Date:
2002-11-13 17:21:28 UTC
From:
To:
My problem is that I can't just cd in and out. "Mounting" and "unmounting"
means making a tgz.

If it'd be as easy as losetup /dev/loopX pbuilder.image; mount /dev/loopX
/mnt/pbuilder. Then one could start and stop working with it whenever one
would feel like.

It's hard to explain - it' just doesn't make it very pleasant to work
with. (Allthough I must say that it's a big step forward for building
packages!)
*t
#168810#40
Date:
2002-11-13 19:01:55 UTC
From:
To:
The necessary hooks should already be available, because
to work with UML, I have added hooks to work with block
devices, but you have not explained yourself very clearly to me,
and I am yet to understand the advantage of losetup ?

Could you give some example cases of why that might be useful,
some theoretical role of what you might enter on the command-line
and it might respond ?


regards,
	junichi
#168810#45
Date:
2002-11-13 22:05:55 UTC
From:
To:
an image.

The reason is simple the lag/delay/ping-time or whatever. The step from
base.tgz to browsing it back to base.tgz simply takes too long. It is a
burden.

If it was a compressing fs in an file-image one could easily make copies
of it like one can now with base.tgz to have different setups etc. but one
could also be quick at changing those setups.

It's a quality which, if not present, does not enable a certain type of
way of working.

The big difference here is not between loopback or not but between
compressed and compressing (or not compressing at all).

To de/compress .tgz takes long (about two minutes here I guesstimate).

I'm not an expert on filesystems that do autocompression though.
*t
#168810#50
Date:
2002-11-13 23:54:21 UTC
From:
To:
The major problem is that by decompressing 100MB of data
is written out to harddisk, with directory hierarchy information.
That is the slowest part of the process on most machines unless
you happen to own an extremely fast harddisk, or run it on RAMDISK.


regards,
	junichi