aps-devel
[Top][All Lists]
Advanced

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

Re: [aps-devel] From source?


From: Wolfgang Jaehrling
Subject: Re: [aps-devel] From source?
Date: Thu, 2 Jan 2003 21:24:11 +0100
User-agent: Mutt/1.3.28i

On Tue, Dec 31, 2002 at 06:33:05PM -0200, Lalo Martins wrote:
> You still have to build at least one arch.

If you do not want to do that anyway, why are you a mantainer for that
package then? ;-)

> Don't take this as whining.  This is most from observing people's gripes
> than personal experience.

Yea, I see the problem now.

> There is, of course, the other side.  Perhaps *you* disagree with someone
> else's build options or other little decision.  What are you supposed to do?

I think the real question is: Does using binary package necessariely
make it hard to build packages from source with custom options?

> Unrelated: having auto-build servers is good.  But it costs money.  A system
> that can do without them is, therefore, easier to keep alive.

Agreed.

> I believe the intermediary step (binary package) is silly and, if at all
> present, should be automated.

Yes, let's automate it.

> That said, no, it is not *much* harder with Debian.  It is just harder
> enough that people end up not doing it and installing it under /usr/local.
> I would like to encourage them not to.

Absolutely agreed.

> > What do you mean with `sometimes they aren't'?
> 
> In the GNU system, there is always source, period.  I (personally) am a
> believer in the "non-Free software is not software" motto.  But in an
> "anarchistic" distributed environment like this, binary-only packages will
> appear, sooner or later.

Yes, this is why I want a way to prevent users from installing
non-free software by accident, and that should be the default.  Robert
has a plan for that, but I am not yet completely convinced that it
will work well enough.

> > That the packages need to be build locally is actually a very huge
> > problem, because building software makes GNU/Hurd crash every few
> > hours currently, and while the situation might improve a bit during
> > the next few month, it will still remain a problem.
> 
> This has to be fixed in the Hurd, not the packaging system.  Fixing things
> in the wrong place is the origin of a significant part of computer problems.

I am aware of that, but I am realistic enough to see that we have to
do some things different if we want to get a usable system in a
reasonable time.  My personal opinion is that we should implement
non-optimal solutions now *BUT* ensure that fixing them will be
possible in the future without significant problems.

> However, this could be handled by a "public cache" layer of binary packages,
> as previously suggested.  This layer would usually only contain the most
> common builds, but while the Hurd is unstable, it could be - without changes
> - made to have them all.

How might that `public cache' look like exactly?  This is all a bit
vague for me.

> > That it is slower to install software is also problematic because at
> > least 95% of all users don't care about `optimized' packages and are
> > not (yet) experienced enough to take advantage of the flexibility, so
> > _requireing_ users to build from source has no advantage for most of
> > them and they will see only the disadvantage.
> 
> These 95% will, IMO, stick with RedHat or SuSE at least for the next 5
> years.

I think that there are also people who have not much experience, but
still understand software freedom.  Sure, there are only very few of
them currently, but these users are what I care about most.

> Of course, as pointed in my post about USE, the flexibility has to be given
> an interface that more people (perhaps not these 95%, but at least some) can
> use.  And, sorry, but if you want to use GNU, at least *I* expect you to do
> enough of your homework to know if you want ESD or ARTS (even if I am
> prepared to ask you that question in a pretty GUI window).

If you also explain to me (in a pretty GUI window ;-)) what they are,
then this is probably fine with me.

> Back to topic: a Linux port is IMO useful because right now it would provide
> a more solid ground for development.  As you mentioned previously (in
> another message), each part of the system can be developed independently,
> and things like dependency, versioning, installing/removing/updating (and
> building, if I get my way trough) can be done in GNU/Linux while the Hurd
> matures.

Yes, but this is unrelated to a {GNU/,}Linux port.

> > I wrote a proposal already, see the list archives.  Comments on that
> > are very welcome.  I suspect it contains a few flaws which I did not
> > discover yet.
> 
> I have read the whole archives (not a lot to read) and found nothing related
> to this.  I'm reading again: (pause) nope, still haven't found.  Perhaps it
> was in some message not forwarded to the list?

Probably.  I will forward it to the list again (if no one else does).

> After the re-read, I get a very vague impression that you're wanting to use
> settrans for installation.  That would be conceptually very cool.

I don't remember saying (or thinking) that and am not sure why this
would be cool.  Maybe I am just confused at the moment.

Cheers,
GNU/Wolfgang



reply via email to

[Prev in Thread] Current Thread [Next in Thread]