[Top][All Lists]
[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