[arch-dev-public] Repository cleanup [current] and [base] --> [core], this weekend!

Simo Leone simo at archlinux.org
Wed Sep 12 12:35:20 EDT 2007

On Wed, Sep 12, 2007 at 05:06:04PM +0100, Phil Dillon-Thiselton wrote:
> I have intended to go back and join all the discussions about the
> "non-free" repo but I have not had time so I will have to dive in
> here.
> In my opinion it is totally unnecessary.  I agree that support for
> id-ing non-free pkgs should be fully implemented in pacman, indeed
> this is what I had thought the license field was for.
> As for the case of magazines and dumps of the repo - it's a scriptable
> solution.  This can either be done locally by the downloader or
> server-side by us.  How hard would it be to have pacman churn out all
> the URLs for free pkgs in [extra]?  Not hard at all I think.  This can
> then be used with wget.  pacman support also has much broader
> benefits.
> That's a much more Arch-like solution than a separate repo.  I'm also
> of the opinion certain people want a non-free repo because it will
> tidy up some "loose ends" with regards to the non-i686 arch projects.
> I'd hate to see time and emphasis diverted from pacman development to
> achieve something this spurious.
> As for our own DVD of [extra]...keep up, guys.  It's 2007.  DVD is
> virtually a synonym for "movie on disc" and even they are now being
> phased out in favour of downloads.  The market is moving away from
> solid state format, not towards it.  Arch is about 4-5 years too late
> for a package snapshot on hard media.
> Now, I am aware that there is an argument that there are some people
> in some parts of the world that don't have reliable internet access
> and so can't access the repos.  I have the following questions on this
> case:
> * Can someone demonstrate 10 cases of this here and now?
> * Should these people be using a rolling release distro?
> * Why can't they make one DVD for multiple uses themselves?
> * What is the benefit to Arch of producing a DVD?
> * Why can't creation of the DVD be scripted using pacman features (as
> outlined above)?
> * If a lack of a DVD is restricting our audience then when did we care
> about that?
> I know my opinion is hardly a deal breaker but I just don't get the
> point of this whole non-free thing.
+20, seriously.

When are we going to stop finding ways to cater to every oddball use
case and get back to the basics?
* If a magazine wants to distribute us on DVD, while we're more than
  willing to help them achieve that by generating custom images for
  them (or ideally they can do it themselves), etc, there is NO, 
  I REPEAT ABSOLUTELY NO REASON, we need to restructure our repos
  to accomodate that.
* If someone doesn't have a whole lot of bandwidth, maybe they shouldn't
  be using Arch. Oh I know I'm a jerk now. Seriously, arch just... you
  know... isn't....for some people. And that's perfectly OK. Just like
  debian isn't for us, and that's ok. You don't see them scrambling to fix
  all the little things that keep us from using it do you?

What I'm trying to get across here is that some parts of this dev team
have adopted a reactive development model. By this I mean that the
majority of your devel is driven by whatever issues come up, as they
come up. Do you realize why that's bad?

Typically projects will go through some solid research and plannning to
avoid this situation. I've heard that when the developer has a solid
understanding of the problem, they often develop more generic tools that
have more unforseen uses in the future than when they develop
reactively. This is why, for instance, pacman is so versatile in that it
alone can be used to solve all these problems (like phil said). Gee,
what a great tool.

Sorry for the slight OT, it's kind of related.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20070912/b9a23e06/attachment.pgp>

More information about the arch-dev-public mailing list