Elliot Dray wrote: > > To build the package it needs root-like privileges and so use > > fakeroot. But don't use real root. > > Is it just because of good practice why you shouldn't use root? there is no > technical reason, is there?
Good practice, good sense. Building packages implies debug and development. Which implies bugs. Running as root places you completely at the mercy of any bugs that exist in the package building scripts. The possibilities range from simple things like just accidentally changing the permission or ownership of a system file to much more serious damage. At the time it becomes a .deb package programs like 'lintian' can check for many classes of problems before you install it using real root and provides a safety net. > > If there are build dependencies then the apt-get build-dep should > > install them. If there is a dependency upon another package in > > unstable which needs to be backported then you need to start again at > > the beginning and to backport that package first. > > So you have to find the root and work forwards, ok. Does anyone have a > script that can do this or is it a by hand job? You will have to work through those by manually. > > > 1c)do you end up with a system at testing or unstable by > > > stealth, because it has recursively installed so many products? > > > Yes, no, maybe. It depends upon what you are installing and how you > > define things. > > As a test I was thinking of evms (only as a test) or request-tracker3. I > suppose it depends on how many programs you have to backport in order to > get the one you want to backport successfully. I'm not sure what you mean > by how you define things? If you define stable as all of the shared libraries and you are required to backport a shared library then you are not running stable anymore, at least not for that shared library. If you define stable to be just glibc-2.2.5 then when backporting other libraries you are still running stable. If you backport GNU coreutils from unstable to stable you are not changing libraries at all and so would seem to be running stable still, but the basic command set is now is different and has different options in some cases. I think that pushes you out of stable and into unstable as well. I see it as basically a judgement call as to what you are changing and how important it is to the system in general. As with most judgement calls there is room to squirm around. But keep this in mind. If you write an application that uses a feature not found in a stock stable release and give it to someone who is running a stock stable release then it won't run there. Certainly if it runs on your machine that you developed it upon then you could no longer claim that you were running stable because if you were it would not run there. Or if you were running stable then the aplication would also run for the other person running stable. In some ways 'stable' is a handle that grips the entire set of versions of packages all at one time. Which is why release names such as potato and woody mean something but testing and unstable names don't mean anything unless you also put a date with them and even then it would be harder to correlate dates to actual package versions. > > What are dependency files? I could not deduce to what you were > > refering. > > I was basically refering to the files that get installed as part of the > build-dep, once you've managed to build your backport can you remove these > files that were pulled down in order to satisfy the dependencies so that > your package would build from source. Again this was what was said in > another post awhile back. Oh, okay. Yes you can remove those. But if you try to backport again you will just need them again. Those are stock packages for stable at the time you install them. It is usually easier just to leave them installed. You might check out the 'deborphan' and 'debfoster' packages which provide global ways to manage packages. > Ok, understand, but wouldn't it be viable for some packages which have few > dependencies (and backport easily) to be backported at the time of creation > by the developer? just a thought This topic gets discussed, at great length I might add, every so often in debian-devel. In summary anyone could set up a track for this purpose. But so far no one has decided to champion such a track enough to actually do it. There are some tricky issues so it is not quite as simple as you might think at first guess. And remember this would be needed across 11 architectures too. Bob
pgp00000.pgp
Description: PGP signature
