Re: [aps-devel] From source?

[Lalo Martins]

On Tue, Dec 31, 2002 at 07:41:40PM +0100, Wolfgang Jaehrling wrote:
> On Tue, Dec 31, 2002 at 02:02:48PM -0200, Lalo Martins wrote:
> > 1: less pressure on the packagers.  You don't have to build N binary package
> > files, just a (guile) script that builds the stuff.  As a former Debian
> > packager, I can assure you that this is no light issue.
> 
> That is why there are servers that build the packages for all the
> architectures, no?  I currently fail to see how this is an advantage.
> You have the experience to know it better than I do, so please explain
> it to me.

You still have to build at least one arch.  Using Portage, for minor
releases you just have to check if the upstream folks didn't break your
script (by changing the build process), then bump up the script's name and
upload it (cvs add; cvs ci). Using my dreamworld system, you have to check
if the upstream folks didn't break your script, and if they didn't you take
absolutely no action.

Now a detailed explanation of why this is a problem in Debian:

most people have bigger priorities in life bigger than being a Debian
developer.  Some work, some study, some maintain their own Free Software,
some have families, etc.  Alas, the people who *don't* have bigger
priorities (I mean, people for whom being a Debian dev is very very
important) still tend to have responsabilities to Debian itself that go
before building packages - providing support, admining servers, etc.

When an upstream package has a new release, you package it ASAP.  But life
is not perfect and sometimes ASAP can take a few days.  If you don't do it
in a matter of hours, the usual policy is that someone reports a
wishlist-priority bug in the BTS titled "New upstream release".  Which is
fine.  But if you take more than 2 days, for any package with more than a
handful users, you start to get a lot of heat.

If it is an important package with lots of dependencies like SDL, it doesn't
stop there.  After you make the release, you will still get heat for a few
weeks from people who disagree with your build options, or some little
decision you (in your right as maintainer) had to make.

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

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?


This is not a very heavy burden.  But we have to keep this in context that
packaging software is *not* a top priority for *anyone* I know.  Even the
most hardcore hacker probably would prefer to be hacking.  So, if we want
people to do it, we have to keep it doable.


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

> > 2: customizability.
> 
> Yes, this looks like a valid point, though not a major one since one
> can do it the way Debian did.

Debian didn't.  They waltzed around the issue in a way that is already
starting to fall apart and blow up.  Returning to my example, the Debian SDL
packages are very, very far from offering the full range of targets SDL
supports.

> > 2.5: (sub-item of 2) optimization.
> 
> I personally will probably never understand why that is an
> advantage... *shrug*

It is an escape from the Wintel cartel... I can get better performance
without spending money on upgrades.  And performance actually means
something for some people; on the same machine, with Gentoo (optimized), I
can keep gnome-terminal (with 4 terms), galeon, evolution, gaim, emacs and
zope running at the same time (all this with gnome2).  On Debian if I wanted
evolution I had to close something else (usually zope) or the system would
crawl.  The way I work now is much better because I have access to all the
tools necessary to my work with a task-switch, and this makes me more
productive.  And all it took was a command-line argument.

> > 3: portability.
> 
> How is this more portable than setting up an autobuild-server for some
> architecture?

It's not.  But it's cheaper and faster.

> > 4: tweakability.
> 
> A very good point, but is this that much harder with e.g. Debian?

With Debian and the RPM-based distros: You unpack the sources, tweak, build
a binary package (.deb or .rpm) - which is unfortunately more obscure to do
in Debian than in the RPMs - then you install your locally-built package.
The first step - unpack the sources - can be more or less complicated, on
Debian it is enough to run `apt-get source pkgname` (except for the fact
that the source package name doesn't always correspond to the binary package
name and then you have to investigate it).

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

) unpack
) hack
) build
) go for coffee
) seee error in the middle of build
) hack more, repeat previous 3 steps till you have a .deb (.rpm)
) dpkg -i ../foo*.deb  (rpm -uvh ../foo*.rpm)
) go for even more coffe assuming you can still stand it
) test
) realize you made a mistake
) go back to step 2, if this is the first time you reach this node;
  otherwise scream, and go to bed, or for a walk.  I personally suggest ice
  cream, something containing chocolate.


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.


> > Also, it operates on the assumption that the sources are available
> > somewhere, without even considering for a second that sometimes they
> > aren't.
> 
> What do you mean with `sometimes they aren't'?

You know, I almost added exactly these words in parenthesis to the paragraph
above.

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.

This, however, is verging the off-topic.  What I meat is: operating on this
assumption is a feature, not a problem.


> > The single downside is that installing packages is much slower.
> 
> 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.

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.

> 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.  ("What do you mean, there is something else?  I thought Linux (sic)
was made by RedHat (or SuSE).  What, this you use is not Linux?  Gee, I love
Linux, I don't want to switch again.")

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).


> > (The Linux port of aps would then...
> 
> I personally will not even think about a port to GNU/Linux

(off-topic remark: note that I mentioned a "Linux port".  This was not a
mistake, as the difference between both versions is exactly the kernel: the
Hurd version can use translators, the Linux port can't.  As RMS once said,
"there is no such a thing as a GNU/Linux kernel".  If aps is the packaging
system of the GNU system, it makes no sense to port aps to GNU; if I have to
do any porting at all, it is kernel-related.)

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.


> > What form does the package take when under /packages?  A file?  A directory
> > tree?  Containing what?  How are versions represented/managed?
> >
> > How does the user express the desire to install/update/remove a package?  By
> > running a program, as usual?  What about installing right off CVS, is it
> > possible at all?
> 
> 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?

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 will
save the technical comments for after I get real answers ;-)

> > Sorry, in this case I don't understand what are you trying to build here.
> 
> I am also not _exactly_ sure about what what Robert plans, I just know
> what I want: The GNU system.  Preferably at the 20th anniversary of
> GNU in 2003.

Then by all means I'm staying, someone add me to the savanah project,
because that is exactly what I want too.

<half-silliness>
I'm technically happier with Gentoo than Debian, but it bothers me a bit
that it calls itself "Gentoo Linux" (and Gentoo is a species of penguin).
It makes me want to switch to something named after a species of wildebeest.
</half-silliness>

[]s,
                                               |alo
                                               +----
--
            Those who trade freedom for security
               lose both and deserve neither.
--
http://www.laranja.org/                mailto:address@hidden
         pgp key: http://www.laranja.org/pessoal/pgp

Eu jogo RPG! (I play RPG)         http://www.eujogorpg.com.br/
GNU: never give up freedom                 http://www.gnu.org/