You are not logged in.
Pages: 1
repo: https://gitea.com/easydeb/easydeb
easydeb, is a fork of makedeb, that in turn is a fork of makepkg from arch. It takes recipes and builds deb packages. It's very similar to PKGBUILDs in the AUR.
The goal, is to have a packaging tool that is more accessible. It's written in bash, and the recipes are in a single bash file. Long term the goal would be to have an "AUR" but for debs. Currently i have a bunch of examples here: https://gitea.com/DUR you are welcome contributing your own recipes (expect minor bugs, i made a mass migration).
Debian packaging is just bad at several levels. Technically is overly complicated. For example, links have to be declared in a special file, here, you just use ln -s. It uses makefiles, here it's just bash. The barrier to entry for packaging in debian is just too high, from too much bureaucracy to very high quality requirements. Yes, high quality is a problem here. Especially since there's no place like an AUR to allow people to be bad until they gain experience and stop being bad. While debian maintainers are typically overworked while the docs tell you immediately don't bother people with questions, just rtfm. And there's a heavy bureaucratic procedure to get admitted. The whole thing is very intimidating to interested future maintainers. This is really terrible, any institution that doesn't prioritize the new generation, is guaranteed to die. With wikipedia, you can see a drop in the number of admins, while old admins say they would never had become admins today because of the very high standards. I don't know if they are statistics somewhere about debian maintainers, if they do, they should be showing alarming trends. If you think about it, arch shouldn't have existed, sid should have been arch and we should had have a DUR.
It has basically 20 years of development from arch devs, it's not alpha quality, but i made a bunch of changes lately. So expect some bugs.
I'm proposing that devuan makes easydeb the official packager and creates a AUR clone. You must have extra server capacity, you could use gitea to keep it simple and lean and a lot of you are sysadmins so you know how to do it securely. An official announcement would be picked up by tech news, and we would see an initial spike of interest. This will lower the barrier to entry for new maintainers. And also allow a place to put less polished packages.
I think debian is slowly dieing and we need a realistic long term strategy to fork it. I think the rust/Wayland/systemd bullshit will cause a bsds type of split in the linux world. debian has become a product.
Offline
Interesting stuff and I agree with you about the need to simplify things, tagged so I can check out your work later. A DUR would be nice to have, I have some things that could go into it myself. Thanks for posting!
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do.
Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
@exponentialmatrix just looked at this and found the contradictory documentation extremely confusing.
Even the obvious action of running 'make' after git clone does nothing except echo 'true' to the console.
Why are the files split across two git repos ('easydeb' 'easydeb-git')?
Delete or move anything irrelevant or plain misleading, you are using git, it is trivial to reinstate it later.
I get that no programmer likes writing documentation, but you could at least provide a 'build.sh' script to give the uninitiated (me) a clue as to what is supposed to be done to get started.
Offline
You didn't read the readme in easydeb
. Clarify what's confusing.
This is a deb packager that packages it self... You expect i'll use "make install"?
1. you download and install the deb package of the release from easydeb. https://gitea.com/easydeb/easydeb/relea … f3_all.deb
2. easydeb is the real repo
3. easydeb-git is the recipe to package it self. it follows aur convention. This packages the latest git version. Because of the way it works, i couldn't put it inside the main repo. You clone, you enter the folder, then run easydeb. (if build dependencies are missing, it will request "easydeb -s" for installing them, you can block the lengthy checks with "--no-check" )
4. https://gitea.com/DUR a bunch of examples of recipes. Some depend on others to build or install. Also some maybe a bit buggy, i made some mass changes latelly.
5. help:
man debbuild
man easydeb
easydeb --helpdebbuild is help for the DEBBUILD format
the other two are for the command. If something is confusing, tell me.
expect some bugs. Just report them, here or there is fine.
Offline
BUILDING is outdated and indeed confusing.
https://gitea.com/easydeb/easydeb/src/b … UILDING.md
i updated the docs.
Last edited by exponentialmatrix (2025-11-07 16:46:40)
Offline
@exponentialmatrix, thanks for that, I will 'git pull' and start again when time permits.
BUILDING is outdated and indeed confusing.
Yes, after 20min of battling I figured out what I was 'supposed' to do.
Chicken->Egg->Chicken building is always fun ![]()
Offline
you don't need to build easydeb, there's a deb in the releases.
https://gitea.com/easydeb/easydeb/relea … f3_all.deb
Offline
you don't need to build easydeb, there's a deb in the releases.
https://gitea.com/easydeb/easydeb/relea … f3_all.deb
You could have led with that. ![]()
Grabbing a copy now.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded October 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do.
Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
@exponentialmatrix
you don't need to build easydeb, there's a deb in the releases.
Oh you really don't know me do you.
easydeb itself (once self-packaged) needs to go under /opt and so does anything I package with it
1) Non-package software should install under '/usr/local' not '/usr'
2) Non-official packages should install under '/opt/<package>/' not '/usr'
And that was just the first 20 minutes of building, I am sure more 'issues' will find me.
Like many mult-developer projects, there is a ton of inconsistencies in the source, not sure I have the skills to fix them.
Of course if this ends up in the official Devuan repo all that goes away and I can sleep again. B-)
Somebody ? LeePen ? Pretty Please ?
Offline
you weren't supposed to install it directly. it's "make package", not "make install". It's for packaging. Given the circumstances i don't see the point of a make install. Yes i know about /usr/local .
/opt is when all the files are thrown in one folder, example: /opt/firefox /opt/brave . Plenty of non-distro packages install in /usr . You are breaking convention. Yes, i know many third party apps just dump all their stuff in opt.
I'm assuming you found FILESYSTEM_PREFIX ... i guess you can install in /opt/easydeb . I didn't tested moving the prefix in the DEBBUILD. What you are doing is too weird. You are complicating your life for little benefit.
if it's not broken, don't fix it.
Offline
you weren't supposed to install it directly
Wouldn't build a deb until I did.
Plenty of non-distro packages install in /usr
Not in my back yard!
I will permit installations under ~user/ on the systems I manage, after I have made it abundantly clear that any issues will be resolved by 'rm -fr ~user'
Non-packages are built from source and installed under '/usr/local'.
Non-distro packages are also built from source and uploaded to the repository sever for installation by apt.
You are breaking convention
No I am maintaining it.
I'm assuming you found FILESYSTEM_PREFIX...
Yes, it's broken.
if it's not broken, don't fix it.
See above.
Not giving up yet, the peripheral source scripting is overly complex (any app should know where its own files are without relying on environment variables) but the actual meat looks good.
Offline
The convention for opt, is to put there applications that expect all their stuff in a single folder. You are just wrong here.
It's not broken, what you are doing is not supported.
in src/easydeb.sh.in edit these variables to your liking, all the scripts are in src. see in test/util/util.bash the easydeb function as a reference. I rigged the tests to use the repo version. You could use this to have it package it self with the provided DEBBUILD.
LIBRARY="${LIBRARY:-"@FILESYSTEM_PREFIX@/usr/share/easydeb"}"
EASYDEB_CONF="${EASYDEB_CONF:-"@FILESYSTEM_PREFIX@/etc/easydeb.conf"}"
EXTENSIONS_DIR="${EXTENSIONS_DIR:-"@FILESYSTEM_PREFIX@/usr/lib/easydeb"}"you can set FILESYSTEM_PREFIX and DESTDIR to /opt/easydeb with the make commands from build.md (updated, if didn't notice)
That should mostly work, then manually fix the remaining glitches. man and bin will be out of path, maybe more. I'm assuming you know how to symlink them in local. You could do these things inside the provided DEBBUILD.
if you still have problems just ask.
the translations don't exist. ignore
Offline
The convention for opt, is to put there applications that expect all their stuff in a single folder. You are just wrong here.
https://tldp.org/LDP/Linux-Filesystem-H … l/opt.html
Or if you like pictures
https://docs.redhat.com/en/documentatio … _hierarchy
It's not broken, what you are doing is not supported
Its not a bug, its a 'feature'. Where have I heard that before....
you can set FILESYSTEM_PREFIX and DESTDIR to /opt/easydeb ...
That should mostly work ...
Mostly isn't completely, it aborts building a deb package (on my setup), and does not put all the files under the correct hierarchy either.
I'm assuming you know how to symlink them in local.
Not in my back yard!
Either installation from source under '/usr/local' or installation from package under '/opt', definitely not mixed!
if you still have problems just ask.
the translations don't exist. ignore
OK thanks, willdo.
Relieved about the .po translation files, had a nightmare time once performing a trivial re-labelling of 'Wastebasket' to 'Rubbish' just to make it fit the desktop.
If I end up with anything half-useful I will let you know where, so you can pick over the bones.
Offline
see latest update, i added make install with default to /usr/local. I haven't fully tested /usr/local because i don't want to install untracked files. It worked with normal packaging and in local folder it looked good with usr/local . Look for errors i might missed, including docs.
make install RELEASE="unstable" TARGET="local"current translations are just AI place holders for testing. release and target are just for version tracking. Translations not supported here, they use gettext and don't know if it's possible to use them in /usr/local .
Offline
in practice opt is used the way i described it. Your document is 20 years old.
Offline
@exponentialmatrix, that last commit made a significant improvement.
So much so I threw away everything I had done and have spun up a clean container to start afresh.
document is 20 years old
and ?
There is 'code' you are using that predates those 'words'.
TL;DR; For the curious that don't already know...
Some significant issues with installing non-official packages (packages not from Devuan repos) are:
package name collisions
package conflicting dependencies (e.g different version of the same library)
file name collisions provided by the package (handled by 'alternatives' for official packages)
conflicting configuration files provided by the package
These issues could potentially break the OS, and/or system packaging database making recovery extremely difficult.
Using the following hierarchy tree goes a long way to avoiding collisions between unknown packages/contents.
Unfortunately, too many packagers think they know better and do not comply with this standard.
/opt/acme/calculator/bin
/opt/acme/spreadsheet/bin
/opt/acme/spreadsheet/lib
/opt/ms-calculator/bin
If the system administrator chooses (entirely their choice)
symbolically linking in /opt/bin and trivially adding /opt/bin to $USER's $PATH
/opt/bin/calc -> /opt/ms-calculator/bin/calc
Offline
@exponentialmatrix, I can now build an easydeb deb package targetting '/opt' thanks to your latest commit and a couple of tweaks to DEBBUILD.
I will now work on spinning up another clean container, install the built easydeb package and play with https://gitea.com/DUR to test it.
DUR is new to me, so please bear with me if my reports are untimely.
Do you have a preferred <provider> name for the hierarchy
'/opt/exponentialmatrix/easydeb/' (useful if you author multiple packages, say against a common library)
'/opt/exponentialmatrix-easydeb/'
Or something else ?
Offline
one author can package a library and then an other one use it. libs expect to be seen by everybody. And packages can also change authors.
The convention is to package them normally, you are admitting it your self. You are trying to swim against the current. Conventions change. Back then distro packages where dominant, now external packages are significant.
The potential problems you describe can be managed. If you are doing something critical you'll triple test it anyway. It's up to the user not to over do it.
For the naming convention you create a new standard. The AUR has 100.000 packages and they don't do that. Rename them package-opt to distinguish them from normal packages. The convention is to append something at the end of the name if your package is some special variant. For example -git for git repo packages, -bin for upstream binaries, -wine for windows stuff, -somepatch for a specific patched variant etc.... To keep in line with expectations, -opt packages should be bundling all the stuff the base system doesn't have. So no external libraries, just /opt/package and named package-opt . It's that reasonable to you?
Offline
external packages are significant
Not in my back yard, on my workstation I have one.
This is *exactly* where Debian went wrong, this is Linux not Windows, respect the choice.
Dictating to system implementers tying their hands when they (Debian) have no idea what the system is going to be used for or how it is to be used.
-- snip --
I have deleted the rest of my response, the first section says all that needs to be said, going over old ground is non-productive use of my time.
Offline
what about the -opt part?
Offline
easydeb sounds interesting, will definitely look into it.
I will need to build a couple of packages of apps for Devuan 6 soon as the included versions are too old for my needs, I guess that could be an occasion to try out easydeb.
I think debian is slowly dieing and we need a realistic long term strategy to fork it. I think the rust/Wayland/systemd bullshit will cause a bsds type of split in the linux world. debian has become a product.
I think Debian suffers from the fact that many devs are actually employed by Ubuntu and even IBM (Redhat) therefore they are pushing the agendas of these two corporations onto Debian.
A true community distro should not have devs that also work for commercial distros.
I very much agree with your sentiment that a split between the corporate Distros and the true community distros will be inevitable and actually desirable and will eventually happen.
Last edited by tux_99 (Today 20:51:10)
Online
Pages: 1