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

Re: Guidelines for creating subpackages?



Yaakov Nemoy wrote:
On Dec 1, 2007 9:03 PM, Jesse Keating <jkeating redhat com> wrote:
This is the classic argument.

"We need subpackages!"

"Why?"

"Because it will make Fedora better as a base!"

"Why?"

"Because it will!"

"How?"

"Because it will!  If you don't get that, then your dumb!"

For those "dumb" people, the more granular the packages are, the
easier it is to pick and choose what you want.  You have more
"choice".  If the packages are lumps of things, it's very hard to pull
out what your 1% use case needs and doesn't need.

I feel the most important thing must remain ease of installation for end-users. If you "yum install foo", you expect foo to be fully working after installation (and how many dependencies it pulls is not necessarily important if you're using yum directly). Remember we don't really have a mechanism in place to say "since you just installed foo, you should really consider installing foo-extras, foo-extensions and foo-plugins as well.

And then there's installing from pirut. If I want to install clamav, I open up pirut and search for "clamav". I get 17 packages. Which one do I have to install to have a sufficient setup ? Splitting packages to make dependencies easier to manager is a good idea, but first we may want to think about ways to make this less confusing to the end user. When I search for clamav, I'd like to see a big red line for the main clamav installation line (with all the dependencies it will pull hidden from view), and a side panel with a list of optional packages (plugins and al) with descriptions. Do we have enough metadata right now to produce something like this ?

-denis


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