FeatureSpecification: apt-third-party

[Hervé Fache]

Maybe a stupid idea, but what about having a sort of unionfs of the home and /?

Let me explain (that feels very much off-topic for this list):
- Put your actual home in $HOME/$HOME
- unionfs $HOME /, with $HOME rw and / ro

Then, as a user you can install using apt-get in /usr, /etc ... or in
fact, in $HOME/usr, $HOME/etc ..., which your particular view of the
system. The actual / is unchanged.

Of course, you might want to prevent the user from accessing some
things, like /etc/apt for example, so they don't start running dapper
on a breezy server.

Also wanted: a way to remove a file from the users view if it becomes
available (and identical) in /, in case root decides to install the
package many users have installed locally.

That means we could have a klik-type of install, using good-old-proven apt-get.

Does tha make sense? Any interest?

Hervé.

P.S.: please redirect to other list if appropriate, and tell me where
to register to it ;-)

2006/4/5, Jerry Haltom <wasabi at larvalstage.net>:
> No. This spec doesn't propose or try to handle anything regarding
> installing into $HOME. Doing that, using dpkg, is going to require some
> modification of dpkg maybe, and definitely custom packages, at this
> point.
>
> I also don't think the demand for that sort of thing is as big as some
> people seem to think.
>
> Programs which contain their own update mechanism have always been a
> problem with Debian. Usually we end up turning their own update
> mechanism off and pushing it manually.
>
> I think part of this goes away when it becomes the third parties
> themselves who are using apt... then could then push their updates for
> Ubuntu/Debian using apt... or not. Up to them.
>
> On Wed, 2006-04-05 at 05:30 +0200, John Nilsson wrote:
> > On Sun, 2006-04-02 at 20:03 -0500, Jerry Haltom wrote:
> > > The installed software should track updates from the ISV
> > > automatically and integrate into the existing infrastructure.
> >
> > Would there be room in this project for single user installs (i.e.
> > non-root, installed in ${HOME}).
> >
> > I recently got quite frustrated by how hard it was to use rubygems on
> > Ubuntu. This is the three choices I saw:
> >
> > 1. You use the packaged gems and lose all the flexibility of rubygems.
> > 2  You use gem as a system wide manager for rubygems and thus losing the
> > comfort of knowing that apt/dpkg is in control over the system.
> > 3. You use gem as a ${HOME}-isolated installation, thus gaining maximum
> > flexibility and having somewhat more control over the system.
> >
> > it would be great with a fourth alternative:
> >
> > 4. Use an apt-plug-in for rubygems to handle installation of files in
> > ${HOME}
> >
> > I also have Azureus, Eclipse and some other apps installed in
> > ${HOME}/opt so that I can use their update features (which handle booth
> > core updates and plug-in updates).
> >
> > If all these cases could be solved with a single system that would be
> > great.
> >
> > But this may be completely orthogonal to your project.
> >
> > Regards,
> > John
> >
> >
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>


--
In a world without walls and fences, who needs Windows and Gates?