Mailinglist Archive: yast-devel (116 mails)

< Previous Next >
Re: [yast-devel] introduce a package history to remove obsoletepackages
  • From: Ricardo Cruz <rpmcruz@xxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 11 Jun 2008 15:55:58 +0100
  • Message-id: <1213196158.4292.38.camel@xxxxxxxxxxxx>
Qua, 2008-06-11 às 08:14 +0200, Dominique Leuenberger escreveu:
On 10.06.2008 at 18:04, Ricardo Cruz <rpmcruz@xxxxxxxxxxxxxxxxxxx> wrote:
Hi,

I like the idea, though you're making it more complicated than it
needs, but those dependencies are only dead disk space. If they conflict
with something, they'll be removed or upgraded then.

I think there are more important flaws with Suse's package system.
There is no layers in there which would make stuff like what you're
talking about simpler, and could allow for some interesting uses. Of
course, there is a certain terminology that packagers tend to respect.
But most fundamentally, it would be cool if the packages database was
the directory structure itself. This is when the clutter gets in: a lot
of people don't want to be bothered about doing a RPM package, and you
get a mess, because stuff gets installed all over /user, and this can
actually result in conflict if you don't clean it up.

Well, the different points on the disk, where files have to go to, are
perfectly
defined in FHS.

You still need a map and a compass to navigate through it... I think
they are the ones to blame for /media and some added clutter as well.
Just like e.g. /home was eventually created in Unix to cope with
sysadmins using /usr for programs as well as users, FHS is yet another
attempt to cope and built up in all the ugliness and madness of the
past.

Do you suggest something like at good ol' dos where one program was in one
folder?
And all the data of that program was there too?

I don't know if DOS supported shared libraries, or if it even had some
system for common dependencies to be shared, so I would rather refer to
the MacOS 10 for a file system structure to look up to.

I doubt that I would like to live with such a installation on my
system: just imagine having such a system with remote file systems and
then maintain it.

I think the only respect in which such a system could differ than the
current approach in such a use case is in that you couldn't have the
binaries in one location and then program's specific icons or
documentation in another. I'm not sure how beneficial this would be, and
some layering in the system could make up for that. Sysadmins could keep
the libraries part installed in the local disks, while having the
program's remote (or having both in remote disks, but one faster to
access than the other).

Anyway, I prefer to think of regular desktop users. A network of
computers is a different beast, with all the different tools and hooks
to make it easier to deploy the image, the shared resources or etc...
For Linux to ever be accepted by mainstream desktops, besides of course
a sound business model to employ people to do all the undesirable work,
you'll need everyone with some inclination in IT to be comfortable with
this kind of superficial inner constitution of the system in order to
foam its acceptance (population like every teenager out there, which are
the ones responsible for this kind of decision from families, and
employees from IT shops for the rest).

Cheers,
Ricardo


--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >