'm wondering if there is something Debian can do to be even more
> successful in the container world.
You could use dck-buildpackage --create-baseimage to do that.
Feel free to create some target configs, and I'll be happy to add them.
--mtx
--
Enrico Weigelt, metux IT consult
Free soft
get with
dependencies already installed - but I don't like manual things :o)
BTW: one important point w/ dck-buildpackage for me was being able
to specifiy what's in the image. I really prefer to have it really
minimal.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Lin
n't be so nice w/ k8s ...
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
On 05.10.19 03:31, Paul Wise wrote:
> On Fri, Oct 4, 2019 at 10:49 PM Enrico Weigelt wrote:
>> On 24.07.19 08:17, Marc Haber wrote:
>>
>>> Do we have a build technology that uses containers instead of chroots
>>> yet?
>>
>> Something like docker-bu
On 24.07.19 08:17, Marc Haber wrote:
> Do we have a build technology that uses containers instead of chroots
> yet?
Something like docker-buildpackage ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
omatizing
the rollout of fully-configured installations.
One thing seems to be right: folks who always have been hostile towards
the whole concept of distros now have a better excuse.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
timing, we can also release
> build
> dependency updates via stretch-security).
ACK. I haven't had a chance to take a deeper look at the rust/cargo
issue yet (currently too occupied with other things). If anybody could
come forward with a solution, I'd be really glad.
--mtx
--
Enr
equivs magic.
I'll have to think about this ...
> The AppStream metadata format includes a field for "hardware this works
> with", and beignet-opencl-icd has one, but I don't know if any existing
> tools use this field.
I don't like the idea of making driver pac
On 01.07.19 21:06, Enrico Weigelt, metux IT consult wrote:
Hi,
> IIRC the whole things is actually about crypto stuff. Why don't zfs> folks
> just use the standard linux crypto api (potentially introduce a>
new algo if the existing ones aren't sufficient) ?
Addendum:
nux development
(at least as far as I remember).
IIRC the whole things is actually about crypto stuff. Why don't zfs
folks just use the standard linux crypto api (potentially introduce a
new algo if the existing ones aren't sufficient) ?
--mtx
--
Enrico Weigelt, metux IT consult
Fr
cations that treat "no hardware for this driver" as "fatal error"
> instead of "try the next driver".
So, installing an opencl-based package pulls in *all* cl driver stacks ?
Please don't do that. This IMHO clearly belongs into the operator's
hands (or pos
ly debianized branch) and publishes the repos to the outside world,
would be a really cool thing for me. IIRC that should also cover this
'scratch builds' usecase.
I admit, I haven't checked whether gitlab-ci can already do that.
--mtx
--
Enrico Weigelt, metux IT consult
Free s
On 01.07.19 15:09, Andrey Rahmatullin wrote:
> On Mon, Jul 01, 2019 at 03:04:26PM +0200, Enrico Weigelt, metux IT consult
> wrote:
>> On 29.05.19 17:41, Andrey Rahmatullin wrote:
>>
>>>> Perhaps we should update policy to say that the .orig tarball may (or
>>&g
nto buildd.
Maybe it would be better to just differenciate the statistics between
official debian and others (such as downstreams).
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
le git repo and makes
interacting w/ upstream (eg. submitting patches) unncessarily hard.
That's something I regularily see w/ crappy vendor kernels, which then
take lots of time to bring them into some somewhat usable state :o
--mtx
--
Enrico Weigelt, metux IT consult
Free softwar
that by auditable process
(eg. fully automatic, easily reproducable transformations)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
idiered "applicable" (or better: when is it okay not doing
that) and some rules on how the generation process shall be done.
(maybe having some script with a defined name ?)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
ou give me some more details on the intended workflow ?
Why does one need that information at all ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
ory structure to
> record what the most recent rebase is. Obviously I prefer
> git-debrebase since I wrote it - using a different data model - even
> after I knew about git-dpm and its data model. But maybe this isn't
> the thread for that advocacy conversation.
What exactly do
ext-based patches.
git-rebase is one of my primary daily tools.
> If we could figure out a way to collaborate on something like that well,
> it might be a very interesting tool to have.
ACK.
I believe we should set some computable policies on how orig trees are
generated from actual upstream r
d was to capture how people work *within*
> Debian, where a maintainer is still required to produce a .dsc.
I don't think that .dsc really makes the picture so different. It always
can be generated automatically. IMHO, it's only needed as an output
format for creating src repos and as a
ce missing functionality. Obviously, their current
proprietary userland interface can't be accepted for mainline - it
has to be reworked to be conformant w/ standard uapi (eg. we already
have it for things like snapshots, deduplication, quotas, ...)
But it's up to ZoL developers to do the actu
ll superpackage for
all archs, flavours, etc. - instead I'm using separate layer 2 branches
for that.
(for maintaining lots of kernel configs based on some meta config, I've
got a separate tool)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
ly given up the orig tarball - I'm just
basing on their release tags. And, of course, there shouldn't be
anything autogenerated in the git repo - always recreate everything
(*especially* autotools-generated stuff). The orig tarball, IMHO, is a
long obsolete ancient relic.
For upstreams
years, but no success, so I just gave up :(
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
t (github org with same
name). But the interest from dist maintainers was asymptotically
approaching zero, from below.
> Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices
> / repository format"):
>> I'm always cloning the upstream repo, branch o
rst come
the generic (non-deb specific) patches, then the deb specific ones.
No text-based patches, or even magic rewriting within the build process.
The HEAD is exactly the debianized source tree, which is then fed to
dck-buildpackage.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and
ubtree,
some track source tree plus debian/, some w/ extra text-based patches,
some w/ patches already applied in git.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
re). I have no plan to>
rethink about the "get-orig-source" target since there are ... lots> of
weird upstreams in my list...
Maybe we should talk about some of these cases, to get a better idea.
In general, we IMHO should rethink the workflows for creating the actual
buildable debian tree from upstream releases (in many packages that's
still pretty manual and hackish)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
outcome of that would be a generic
way for fully automatically building everything from a debianzed source
tree (eg. git repo) within a minimal container/jail, w/o any other extra
configuration outside that source tree - even for those cases where the
control file needs to be generated, which again needs some deps.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
control.bootstrap) which is used by my build machinery
(dck-buildpackage) in a separate preparation step, when control file
is missing.
But still, IMHO, the debian packaging toolstack is much superior to
anything else i've every encountered.
--mtx
--
Enrico Weigelt, metux IT consu
provide properly
long-term maintained apt repos for the distros and arch's we use).
Okay, it's just a dream, but a very nice one ;-)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
ot;. IMHO not in official Debian
repo, but I've got it hanging around in some 3rdparty repo ...
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
On 19.11.18 20:24, gregor herrmann wrote:
> On Mon, 19 Nov 2018 17:29:37 +0100, Enrico Weigelt, metux IT consult wrote:
>
> (OT, but since I noticed it too:)
>
>> Anyways, Skype doesn't work since 8.30 as it crashes directly on
>> startup.
>
> Apparently it
de, I'm not doing any code changes outside
git, and I'm building packages only directly from git. Frankly, I don't
see any reason why that can't be the standard case.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
gardless of the> maintainer's behaviour.
hmm, looks like good start. But it doesn't really look easy to clone
from different distros and specific or yet unreleased versions.
and one of my main problems remains unresolved: linear history ontop
of the upstream's release tag.
-
-trustworthy code them into a minimal container
w/ fine tuned minimal permissions.
Anyways, Skype doesn't work since 8.30 as it crashes directly on
startup.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
ecific ones
While gbp can help a bit here and there, it still far away from an
fully-automated process.
I'm currently helping myself w/ lots of mappings and import scripts,
but I'd like to get rid of maintaining all these little pieces.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
except for rare cases where upstream history is
extremely huge - like mozilla stuff) would be just branching at the
upstream's release tag and adding commits for removing the non-dfsg
files ontop of that. From that branching the debianized branch,
where all patches are directly applied in git.
to do so), in order to make sure that
nothing in that really complex cmake file can even try build/use any
piece of them.
the package was just meant for an inhouse installation for my client,
so i didn't care much about policies and orig tarball handling - I've
just patched directly in t
affected packages.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
, as it's completely broken and unusable anyways - for several
month now. We could reconsider once the Upstream (Microsoft) manages
get it at least running w/o segfaulting.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
ckager ? Is there any extra quality
gate (before the user) ?
> * default: install files in /usr only
That's bad enough, if the package is of bad quality or even malicious.
Finally, I'd really like to reduce complexity, not introduce even more.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
ht require some local customizations.
(planned for future releases)
I'm also hacking on another tool which automatically clones repos
and calls dck-buildpackage for building whole pipelines - but that's
still experimental and hackish:
https://github.com/metux/deb-pkg
--mtx
--
Enri
pplications, eg. moz).
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
alk to her.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
Hi folks,
is it possible to use the substvars mechanism for the *.install and
similar files, just like w/ control file ?
For multi-version installations, I'm keeping the whole package in a
prefix w/ the version number (see my other mail - nodejs). I don't like
to change lots of files which each
On 04.05.2017 09:26, Jérémy Lal wrote:
> At the moment, in debian, /usr/lib/nodejs is there to store all node
> modules installed from debian packages.
hmm, would that conflict w/ having certain "nodejs-$version" subdirs
w/ the actual engines (the whole tree - not splitted out the several
FHS par
Hi folks,
I'm currently packaging nodejs-7.9 for various deb Distros.
I'll have to maintain some applications that use the fanciest
new features, and precompiled binaries from untrusted sources
(eg. nvm+friends) of course are not an option.
Before I go all of this alone - is there anybody here
On 14.04.2017 14:34, ian_br...@mail.ru wrote:
> I was right -- it IS a Debian Policy violation:
>
> * 4.13 Convenience copies of code *
I've got a similar problem while packaging recent webkit (latest surf
needs a newer one). Their git repo is >GB (!). No idea how much I'll
have to cut out
On 13.04.2017 11:27, Vincent Danjean wrote:
> For me, the first argument explain in the first mail is not this one.
> systemd is not portable on lots of system (hurd, kFreeBSD, ...),
This is just one of many arguments for not making applications
depending on it. (and they shouldn't depend on a
On 17.02.2015 18:49, The Wanderer wrote:
Hi folks,
just digging out an older thread that was still laying around in my
inbox - w/ about 2yrs distance, I hope it was enough cool down time
so we discuss it more objectively about that.
> libsystemd0 is not a startup method, or an init system. It
On 11.04.2017 10:22, Andrey Rahmatullin wrote:
> On Tue, Apr 11, 2017 at 04:22:40AM +0200, Enrico Weigelt, metux IT consult
> wrote:
>>>>
>>>>
>>>> could anyone please give me some insight, was the security problems
>>>> are here exactly ?
&
On 09.04.2017 22:58, Andrey Rahmatullin wrote:
> On Sat, Apr 08, 2017 at 08:28:38AM +0200, Enrico Weigelt, metux IT consult
> wrote:
>>
>>
>> could anyone please give me some insight, was the security problems
>> are here exactly ?
> Extension auto-updating is
could anyone please give me some insight, was the security problems
are here exactly ?
--mtx
--
mit freundlichen Grüßen
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287
On 02.01.2015 17:08, Martin Pitt wrote:
Hi,
> Yes, man dh_fixperms. Shared libraries don't need to and should not be
> executable.
Oh, wasn't aware of that. Just used to that as gcc sets that flag.
Is it a bug in gcc, or are there platforms where +x is required ?
cu
--
Enric
s might have an idea ?
See:
https://github.com/metux/fskit/tree/jessie/master
https://github.com/metux/fskit/tree/trusty/master
the build process is driven by:
https://github.com/metux/packaging
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUBSCRIBE, email
On 25.11.2014 16:29, Philip Hands wrote:
> How is it that Debian changing the default for something on some of
What about the enforced replace on dist-upgrade, which at least
produces lots of extra work and can easily cause systems being
unbootable ?
cu
--
Enrico Weigelt,
metux IT consult
On 29.11.2014 19:15, Svante Signell wrote:
> Since there is no interest in adding a debconf message on new installs,
> I wish for a menu entry in the advanced part of the installer to be able
> to install a new system with sysvinit-core or upstart!
+1
--
mit freundlichen Grüßen
ystemd faction ?
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54812e53.9080...@gr13.net
systemd then.
Same for me. If there really is some functionality which some DEs
really need, why not having an entirely separate tool for that ?
Anyways, I still didn't understand why udev is bundled within systemd.
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUB
:
Why do these things all have to be so deeply interdependent ?
I would even question, why each DE needs it own display manager ?
What's so wrong with all the other DMs ?
Certain DEs (like GNOME and KDE) seem trying to build their own
operating system - I really fail to understand why.
ill install a system w/o systemd ever going into my system -
instead of replacing it later (eg. some option in the installer) ?
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscri
#x27;s meanwhile an efficient solution
for fully on-demand startup (and auto-cleanup) of fcgi slaves
with arbitrary UIDs, and how much overhead copying between
processes (compared to socket-passing) produces on modern systems
(back when I wrote muxmpm, it still was quite significant)
OTOH, for
r computers on the local network seems like
> perfectly reasonable and useful feature to me.
Okay. But WebDAV would be one of the last protocols, I'd consider
for that (maybe for the wide internet, but not for local networks).
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
t a decade ago, I've wrote muxmpm, which ran
individual sites under their own uid/gid, chroot, etc. That made things
like cgixec, php's safe_mode etc practically obsolete.
It was even shipped by several large distros, eg. suse (the orignal
one, not novell).
cu
--
Enrico Weigelt,
metux IT con
the way: didn't GNOME originally have the intention of being
crossplaform, not Linux-only ?
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@l
've got the impression that these guys
still value traditional unix concepts, like using the filesystem
for simple hierarchical data structures and access control, tiny
and easily compositable servers and tools, etc.
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUB
On 27.11.2014 02:18, Josh Triplett wrote:
> gnome Depends: gnome-core, which Depends: gnome-user-share, which
> Depends: apache2-bin (or apache2.2-bin in stable, which is a
> transitional package depending on apache2-bin in unstable).
gnome depends on apache ?
seriously ?
cu
--
Enric
cific stuff has to optional)
b) we will continue to provide the existing alternatives, including
fresh installation (choosable at installation time, or separate
installer images)
c) the init system will never be switched w/o _explicit_ order
by the operator
d) this decision stands until
Hi folks,
just seen that the German translation of the maintainer guide is
quite incomplete.
Perhaps I could find some time for fixing it, if anybody explains
me how to do that ;-)
cu
--
--
Enrico Weigelt, metux IT service
to push a signed tag (to the debianized branch) and let the
machinery run ;-)
cu
--
------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq:
created a .deb via git-buildpackage.
Uploaded it to github, maybe somebody likes to have a look at it:
https://github.com/metux/wwwoffle/
cu
--
----------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 e
n yet, so please let me
know what should be done here.
thx
--
------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427
y* from an git tag without having
an upstream/orig tarball at all ?
cu
--
------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux
* Tanguy Ortolo schrieb:
> Enrico Weigelt, 2011-12-31 03:55+0100:
> > IMHO this is completely wrong, those files should be under
> > /usr/lib/... or maybe even /usr/share/... as they're not
> > dynamic data.
>
> Well, when people install new plugins or new the
m-branch is enough.
cu
--
------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427
* Fernando Lemos schrieb:
> Are you guys applying for maintainership for this huge delta
> you want to introduce between upstream and us?
Actually, yes.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.me
is to provide an consistent, robust
and mainainable environment. Sometimes the distro maintainers
have to bite in the bitter apple and cleanup upstreams's dirt.
cu
--
------
Enrico Weigelt, metux IT service -- http://www.metu
* Tanguy Ortolo schrieb:
> Enrico Weigelt, 2011-12-30 06:21+0100:
> > Which packages ship files in /var ?
>
> Many install directories there. And one of my packages, dokuwiki, also
> installs files under /var/lib/dokuwiki/lib/{plugins,tpl}. These files
> define the default s
or an admin-tool can pick them up)
cu
--
----------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 2
without operators used to look at /etc
and comparing current config with new defaults.
Not sure how Debian handles this, but Gentoo's etc-update
mechanism has shown to be very handy.
cu
--
----------
Enrico Weigelt, m
large hosters have rescue boot), maybe
even using containers etc. But the big problem are the uncountable
existing systems which might become troublemakers with that change.
We need practical and reliable migration strategies first.
In the end, I'm curious if it's really worth all o
t; Things have changed a lot since the FSSTD first came out.
True. But the need for quick and easy system maintenance remains.
cu
--
----------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 em
t thing we could do in this regard is to move some stuff from
> /usr to /usr/share or some other tree that is more convenient for placing on
> a
> different filesystem.
What exacty do you intend to put to /usr/share ?
cu
--
----------
the rest.
cu
--
------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung
upstream packages to meet your
> personal preferences, even if you continue to dress them up as
> requirements.
Seems like you still didn't get the idea. As upstream, you don't
need to do *anything*. That's the whole purpose of OSS-QM: leave
the upstream alone and do the redunda
ybe even as an synthentic filesystem. The
interesting question is how this behaves on high-load scenarios.
cu
--
------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +4
be disabled)
--
------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux
than Gentoo's slotting + revdep-rebuild approach ;-p).
I'll yet have to pull it through my own embedded QM process and
build machinery first, so we'll also get crosscompile fixups etc
as a buy-product here ;-)
cu
--
---
* Tollef Fog Heen schrieb:
> ]] Enrico Weigelt
>
> | Autoconf (w/o automake) offers no means to tell additional m4
> | include pathes (eg. in configure.ac), so that just calling
> | autoreconf (w/o any additional parameters!) can do a full
> | regeneration all on its own.
>
nd pam. That would
also solve the static linking problem.
Perhaps something like Plan9's factotum ?
cu
--
------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
but often can give good hints where
there *might* be some bug. So, IMHO, maintainers should always enable
them for testing and try to fix the problems.
cu
--
------
Enrico Weigelt, metux IT service -- http://www.metux.de/
pho
) which
upstreams tend not to do.
cu
--
----------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 ic
* Neil Williams schrieb:
(forgot attachments)
...
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype
standardized.
>
> Not true. Those things MUST work together in every permutation within a
> specific jurisdiction or people can die. Debian and autotools are
> nowhere near that level of importance.
Probably not. But why not learning from the other areas of engineering ?
cu
--
---
ing
autoreconf (w/o any additional parameters!) can do a full
regeneration all on its own.
Right ?
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig
s, for some I could work around by moving all the complexity
to the distro build system, but I dont wanna open that pandorra box
anymore, so I'll fix the source). And for those packages, having the
source in a modern VCS (eg. git) is a big big bonus
system, handle them in the individual
package itself and provide a common interface, which (for autoconf'ed
packages) looks like this:
#1: ./autogen.sh
#2: CC=.. LD=.. ... ./configure
#3: make
#4: make DESTDIR=... install
cu
--
----
s build descriptors (whichever distro you're
looking at). And if that changes, the distro's package maintainer has
to find out early enough to (manually) adapt properly.
Leaves too much manual works and chances of breaks for my taste.
cu
--
---
1 - 100 of 147 matches
Mail list logo
