Re: [yast-devel] introduce a package history to remove obsoletepackages

Qua, 2008-06-11 às 08:14 +0200, Dominique Leuenberger escreveu:

...

...

...

On 10.06.2008 at 18:04, Ricardo Cruz 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org