[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: backporting Questions

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

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.


Attachment: pgp2D2INVUvNi.pgp
Description: PGP signature

Reply to: