Removing single program from multi program packages

[Mike Jones]

John,

    I see now. I agree, man-power is better spent on things other than
separating the free-cell game from the games package.  I was simply trying
to figure out the reason why, and see if there was some way I could
contribute to giving the users of Ubuntu more freedom on what they have on
their system.

    Thanks for clearing that up for me.
-Mike

On Mon, Mar 23, 2009 at 12:30 PM, John Carr <john.carr at unrouted.co.uk>wrote:

> 2009/3/23 Mike Jones <eternalorb at gmail.com>:
> > Hi guys. Thanks for your detailed replies.
> >
> >     I think I'm having a difficult time expressing what I'm trying to get
> > across. It's kind of a vague notion.
> >
> >     My problem isn't that for me its difficult to either just remove the
> > package entirely (in this case, I don't play any of those games and don't
> > see a situation where I will want to for the foreseeable future. If it
> > decide I want to, I will simply install the package again.) I understand
> > that I can go to the terminal and remove or modify the portions of the
> > system I want to manually. (I recommend that you not suggest that to
> anyone
> > in the future. 60% of my time using Ubuntu is in a terminal, and I am
> more
> > than aware that mucking around in the system is a *bad* idea. I don't
> know
> > what files to modify in what order, and I doubt that it would be easy to
> > find the information within 5 minutes).
> >
> >     The problem isn't that the space required for these packages is
> > bothersome. I'm fortunate enough to have relatively new hardware and
> plenty
> > of storage. The space needed for those extra games is effectively trivial
> > for me.
> >
> >     In terms of repackaging the programs: I am more than appreciative of
> > those who spend their time packaging programs for Ubuntu. Even those who
> > package programs I don't use are appreciated. You're right. It would be
> > futile for me to repackage the collection of programs for my own personal
> > use. That would be silly.
> >
> >     So I wanted to emphasise that I'm not a nieve user. I am a Software
> > Engineering student, and spend a large amount of time doing software
> > development at my job. I know a decent approximation of how the various
> > components that I concern myself with work. Well enough to know what I
> need
> > to look up, anyway.
> >
> >     I think I really wanted to get across was "Whats keeping
> > apt/aptitude/gdebi/synaptic/add-remove/ what-have-you from being able to
> > cherry pick components of a package? Is there some hard and fast
> technical
> > limitation? Would anyone like to offer suggestions to me for where I can
> > look into improving the system? Is it feasable to do so?" Any time my
> tools
> > (In this case add-remove, or the other front-ends for the package
> manager)
> > tell me I can't do something I know I should be able to do, I'm bothered.
> A
> > non-advanced user is going to see that message reply and say "Well why
> the
> > hell can't I remove one of them? Just delete it!" I know they will. I
> heard
> > my brother screaming that the other day when he couldn't remove who knows
> > what. It is non-intuitive to not be able to remove or add single
> programs,
> > and instead be told to install entire packages. I understand the
> realistic
> > reasons why this is so, but it doesn't stop me from gritting my teeth
> from
> > what I see as an annoyance.
> >
> >     I think that I was able to get myself across a little better. Let me
> > know if I was confusing still.
> >
> > -Mike
> >
> > On Mon, Mar 23, 2009 at 9:43 AM, Loïc Martin <loic.martin3 at gmail.com>
> wrote:
> >>
> >> Mike Jones wrote:
> >>>
> >>>    Is there just no way for a package maintaner to not have extra work
> >>> piled on their already hefty load while at the same time we allow a
> user of
> >>> Ubuntu to remove most traces of a program in a package with multiple
> >>> programs without having to also remove the rest of them? Is it worth
> doing
> >>> even if its possible? I think I'm in a somewhat unique position of
> having
> >>> extreme distaste whenever my system tells me I can't do something in a
> >>> counter intuitive way.
> >>
> >> You can remove the program and keep the other ones in the package
> actually
> >> - nothing is preventing you to do so, even the system. The cleanest
> solution
> >> would be for you to repackage gnome-games (or whatever name the package
> is
> >> called) for your personal use, while excluding the programs you don't
> want.
> >>
> >> Quite a lot of work for absolutely no gain, but could we expect Ubuntu
> >> developers and package maintainers to spend days doing that for us while
> we
> >> wouldn't spend the same amount of time ourselves (including the time
> >> googling for howtos and such)? Especially when they already have far
> more
> >> critical bugs to address (like when the programs don't even run, or when
> >> people can't install Ubuntu or run it on their machines ;) ).
> >>
> >> But all in all, nothing is preventing you to do what you want to
> achieve.
> >>
> >> Fact is, the way it's done now allows easy upgrades for millions of
> people
> >> who are quite please to see the selection of programs updated for each
> >> release, while said programs only take a few kb of space on their
> drives.
> >> And to be fair, when people are complaining they can't remove foo
> without
> >> removing bar or ubuntu-desktop, I always wonder why they point to
> programs
> >> that only takes a few kB of space while being oblivious to the hundreds
> of
> >> MB taken by fonts, translations, libraries, system utilities, drivers...
> >> they'd never use in a lifetime, but that are invaluable because they
> make
> >> peripherals, foreign languages documents and other things work out of
> the
> >> box in Linux.
> >>
> >> For space-constrained drives, there's Damn Small Linux, and if we were
> >> shooting for that goal I'm not so sure you'd find so many developers and
> >> packagers in Ubuntu.
> >>
> >> If unused programs are really an issue but you're not so tight on space
> to
> >> use DSL, the Ubuntu server install could probably address your needs
> better
> >> - just chose all the programs that you need one by one, and you'd  end
> up
> >> with far less programs than you'd have just trying to get rid of
> individual
> >> programs in multi-program packages that show in the menus. Such a
> difference
> >> it wouldn't be funny.
> >>
> >> Loďc
>
> Hi Mike
>
> Cherry picking parts of a package is bad for the same reason that
> going in and using rm by hand is bad. The goal of the package manager
> is to keep your system in a sane state and allow you add, remove and
> update things without making it so you cant boot. But with cherry
> picking, the package manager has no way of knowing if you removing
> part of a package means that another package or another application or
> library within the current package will carry on working.
>
> So could synaptic automatically work out the dependencies? Well maybe
> for applications it can see what libraries are linked against. And
> maybe it can scan for files that are referenced. But i think there
> will always be things it cant resolve, it will always be a bit fragile
> etc. So humans will have to maintain the data that describes these
> 'sub packages'.
>
> Of course you can disregard the above paragraph because deb packages
> already support this. You have a single source package and it can
> build the tarball and then there are .install files that say 'these
> files belong with this game, and these files belong with this game'.
> Each install file is just a list of files that the build process made
> that belong in a given package. Then you get exactly the behaviour you
> want, safely. But its more work for the maintainers, as already
> described.
>
> Does that make sense? This is not a technical limitation of the
> packaging format, more of a limitation of man power.
>
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20090323/9f828a98/attachment.html>